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TITLE: METHOD AITO APPARATUS TO OBTAIN SERVICE CAPABH^ 

BACKGROUND OF THE INVENTION 

5 ■ . 

1. Field of the Invention , 

This invention relates to distributed computing environments including Web-centric and Internet-centric 
distributed computing environments, and more particularly to a heterogeneous distributed computmg enviromnent 
based upon a message passing model for connecting network cUents and services, and the discoveiy of services in 
10 such an environment 

2. Description of the Related Art 

hitelligent devices are becoming increasingly common. Such devices range fixm smart appliances, 
personal digital assistants (PDAs), cell phones, lap top computers, desktop computers, workstations, mainframes; 
15 even, super computers. Networks are also becoming an increasingly common way to interconnect intelUgent 
devices so that they ma^ commmiicate with one another. However, there'may be large differences m the computing 
power and storage capabilities of various intelligentdevices. Devices with more limited capabilities may be refencd 
to as small footprint devices or "thin" devices. Tliin devices may not be able to participate in networks 
intercomiecting more capable devices. Howeveiv it may still be desirable to interconnect a wide variety of diferent 
20 types of intelligent devices. 

■me desire to improve networidng capabiUties is ever increasing. Business networks are expanding to 
include direct interaction with suppliers and customers. Cellular phones, personal digital assistants and Internet- 
enabled computeni are commonplace ia both business and the home. Home networks are avaUable for 
interconnecting audio/visual equipment such as televisions and stereo equipment to home computers, and other 
25 devices to control intelUgent systems such as security systems and temperature control thermostats. High bandwidth 
mediums such as cable and ASDL enable improved services such as Internet access video on demand, e-commerce, 
etc. Network systems are becoming pervasive. Even without a formal network, it is still desirable for intelligent 
devices to be able to communicate with each ottier and share resources. 

Currently, traditional networks are complex to set up, expand and manage. For example, adding hardware 
30 or software to a network often requires a network administrator to load drivers and configure systems. Making 
smaU changes to a network configuration may require that the entire network be brought down for a periw^ In 

addition, certam intemgent devices may not supportthe necessary interfeces to communica^ 

What is needed is a simple way to connect various types of intelligent devices to allow for communication 
and sharir^ of resources whfle avoiding the interoperability and complex configuration problems existing in 
35 conventional networks. Various technologies exist for unprovmg the addition of devices to a network. For 
example, marry modem I/O buses, such as the Universal Serial Bus, 1394 and PCI, support plug and play or 
dynamic' discovery protocols to simplify the addition of a new device on the bus. However, these solutions are 
limited to specific peripheral buses and are not suitable for general networks. 

A more recent technology, Jini from Smi Microsystems, Inc., seeks to simplify the connection and sharing 
40 of devices such as printers and disk drives on a network. A device flrat incorporates Pmi may announce itself to the 
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network, may provide some detaUs about its capabilities, and may immediately become accessible to other devices 
on the network Jini allows for distributed computing where die capabilities of the various devices are shared on a 
network. The Jini technology seeks to enable users to share services and resources over a network. Another goal of 
the Jini technology is to provide useis with easy access to resources anywhere on the network while allowing the 
5 network location of the user to change. Jini also seeks to simpUfy the task of building 

network of devices, software and users. 

Jini requires that each Jini enabled device have a certain amount of memory and processing power. 
Typically, a Jmi enabled device is equipped with a Java Virtual Machine (JVM). Thus, Jini systems are Java; 
technology centered. Java is a Wgh level object oriented programmmg language developed by Sun Microsystems, 
10 Inc. Java source code may be .compiled into a format caUed bytecode, vAich may then be executed by a Java 
Virtual Machme. 

Bytecode is computer source code that is processed by a virtual machine, rather than the "real" computer 
machme, tiie hardware processor. The virtual machine converts generalized machine mstruction (the bytecode) into 
specific machine mstructions (instructions that the computer's processor will understand). Using a language that 
15 comes with a virtual machine for each platfonn, the source language statements may be compfled only once and may 
Ihenrun on any platform that supports the virtual machine. The Java programming language is an ecample of such a 
language, and the Java Virtual Machine (JVM) is an example of a virtual machine platform that supports programs 
written in the Java programming language. 

Smce Java Vutual Machmes may be provided for most computing platforms. Java and thus Jmi provide 
20 for a certain amount of platfonn independence. Hie Jini architecture leverages off the assmnption that the Java 
programming language is the implementation language for the components of the Jini system. The ability to 
dynamicaUy download and run Java code is central to many features of the Jini architecture. 

The purpose of th6 Jini architectare is to federate groups of devices and software components into a smgle 
dynamic distributed system. A key concept withm the Jini architecture is that of a service. A service is an eirtity 
25 that can be used by a person, a program, or another service. Two examples of services are printing a document and 
translating from one word processor format to another. Jini allows the members of a Jini system to share access to 
services. Services in a Jmi system communicate with each other by using a service protocol, which Is a set of 
interfeces written in the Java programming language. Services are found andresolvedina Jini system by a look-up 
service: A look-up service maps interfaces indicating the functionality provided by a service to sets of objects 4at 

30 implement the service. 

Descriptive entries may also be associated v»dlh a service. Devices and appUcations use a process known as 

discovery to register with tfie Jini network. Once registered, flie device or appHcation places itself in the look-up 
service. The look-up service may store not only pointers to these services on the networic. but also may store the 
code for accessmg these services. For example, when a printer registers with the look-up service, it loads its printer 

35 driver and/or an interfece to the driver into the look-up service. When a cUent wants to use the printer, the driver 
and driver mterfece are downloaded from the look-up service to the client This code mobility means that clients 
cantake advantage of services from the network without pre-installing or loading drivws or other software. 

Communication between services in a Jini system is accon^Ushed usmg the Java Remote Method 
Invocation (RMI). RMI is a Java progranmiing language enabled extension to traditional remote procedure call. 

40 mechanisms. RMI allows not only data to be passed from object to object aromid the Jmi network, but ftU objects 
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including code as weU. Jini systems depend upon this ability to move code around the netwoik in a fonn that is 
encapsulated as a Java object 

Access to services in a Jini system is lease based. A lease is a graat of guaranteed access over a time. Each 
lease is negotiated between the user of the service and the provider of the service as part of the service protocol. A 
5 service may be requested for some period and access may be granted for some period presumably considering the 

request period. Leases must be renewed for a service to remain part of the Jini system. 

Figure 1 illustrates the basic Jini technology stack. The Jini technology defines a distributed programming 
model 12 (supported by JavaSpaces, leases, and object templates). Object communication in Jini is based on an 
KMI layer 14 over a TCP/IP capable networking layer 16. 
10 Jini is a promising technology for simplifying distributed computing. However, for certain types of 

devices, Jini may not be appropriate. The computing landscape is moving toward a distributed. Web-centric service 
and content model where the composition of cUent services and content changes rapidly. The client of the fiiture 
may be a companion type device that users take with them wherever they go. Such a device may be a combination 
of a cell phone and a PDA for example. It would be desirable for such devices to be able to communicate and share 
15 resources with devices that are more powerfiil, as well as with thinner or less powerful devices. 

In addition, with fbe advent of &e Internet and resulting explosion of devices connected to the net, a 
distributed programming model designed to leverage this phenomenon is needed. An enabling technology is needed 
lhat facilitates clients connecting to services in a reliable and secure fashion. Various cUents fromlMckto thin and 
services need to be connected over the Internet, corporate Internets, or even within single computers. It is desirable 
20 to abstract the distance, latency and implementation from both clients and services. 

The key challenge for distributed computing technology is to be scalable from powerful thick clients down 
to very thin cliente such as embedded mobile devices. Current distributed computing technologies, such as Jini, may 
not be scalable enough for the needs of all types of cUents. Some devices, such as smaU footprint devices or 
embedded devices, may lack sufficient memory resources and/or lack sufficient networking bandwidth to partic^ate 
25 satisfactorily in current distributed computing technologies. The low end of the client spectnim, including 
embedded mobile devices, often have limited or fixed code execution environments. Tliese devices also may have 
minimal or no persistent storage capabilities. Most small, embedded mobile devices do not support a Java Virtual 
Machine. Most code^apable smaU clients run native code only. In addition, most small devices have litfle more 
than flash memory or battery backed RAM as their sole persistent storage media. The size of *e storage is often 
30 very smaU and sometimes read-only in nahire. Fmthermore, the access time of fliis type of storage media is often an 
order of magnitude greatCT than hard disk access time in clients that are more powerful. 

Existing connection technologies, such as Jini, may not be as scalable as desired because they are too big. 

F« example, Jini requires that all participants support Java; however, many small clients may not have the resources 
for a Java Virtual Machine. Furthermore, due to its use of RMI, rmi requires lhat clients be able to download code 
35 and content Jini augment the existing client platform by downloadmg new classes, yWch may pose security 
and size concerns for small devices such as embedded devices. Tmi works by cUents and resources communicating 
by passing code and data. When a client activates a Jini service, the service may return its results to the client, 
which may mclude a large amount of code or content In Jini, a client may call a method and a large object may be 
returned, and thus downloaded. The client may not have the resource to accept the retaimed object In addition. 
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RM and Java itself require a lot of memory. Many small foot print devices may not have the resources to 
participate effectively or at aU in current distributed computing technologies. 

Another concern with existing distributed computing technologies is that they often require certain levels of 
connection capability and protocols. jFor example, Jini assumes the existence of a network of reasonable speed for 
5 connecting computers and devices. Jini also requires devices to support TCP/IP network transport protocol. 
However, many smaller devices may have limited connectioii capabilities. Small devices may have high latency or 
low speed network connections and may not support TCP/IP. 

As mentioned above, Jini requires devices to support Java and thus include a Java Virtual Machine, which 
requires a certaui amount of processing and storage capabilities that might not be present for many small devices. 
10 This also restricts the flexibility of Jini in that non-Java devices may not directly participate m a Jini system. Since 
Jini requires Java, it may be deemed a homogenous environment However, it is desirable to have a distributed 
computing fecility for heterogeneous distributed computing that scales from extremely small embedded devices 
through PDA's and cell phones to laptops and beyond even to the most powerfiil computers. 

Other heterogeneous solutions exist, such as the Common Object Request Broker Architecture (CORBA). 
15 CORBA is an architecture that enables program objects to communicate with one another regardless of the 
programming language they were written in or what operating system they're running on. However, CORBA does 
not address all of the connection issues that are addressed by Jini, In addition, CORBA suffers from similar 
scalability problems as Jini. 

Technology such as Jmi and CORBA use a code-centric programmmg model to define the interfece 
20 between remote components. A code-centric programming model defines programmatic interfeces or API's for 
communication between remote clients or components. The APFs may be defined m a particular programming 
language. The API's must be agreed to by all software components to ensure proper interoperability. Since all 
access to components is through these standards API's, tiie code that implements these API's must be present in the 
client platform. The code may be statically linked into the platform or dynamically downloaded when needed. 
25 Many embedded or mobile devices simply cannot accept code dynamically from a networic due to tiie quality control 
issues involved as well as the reliance on a single language and program execution environment. Data-centric 
models, such as networking protocols, may avoid the dependence on moving code; however, such protocols are not 
rich enough to easily provide for distributed computing and they also lack the ease of programming Avith code and 
other programming features, such as type safety. 
30 Conventional distributed computing systems rely on the abiUty of a program executing on a first device to 

be able to remotely call a program on a second device and have the results returned to ^e first device. The Ranote 
Procedure Call (RPC) is a basic mechanism for remotely callmg a program or procedure. CORBA and Jini are both 
based on the ability to remotely invoke program metiiods. However, conamunicatmg by passing code or objects, 
such as in Jini or CORBA, may be somewhat complex. For example, as mentioned above. Jim uses the Java Remote 
35 Method Invocation (RMT) to communicate between services. In order for a client to move Java objects to and from 
remote locations, some means of serialization/deserialization is needed. Such current fecilities in. the Java 
Development Kit (JDK) rely upon the reflection API to determine the content of a Java object, and ultimately that 
code must consult the Virtual Machine. This code is quite large and inefficient 

The fimdamentai problems with the current method for doing serialization/deserialization include its size, 
40 speed, and object traversal model. Code outside'the JVM does not know the structure or graph of a Java object and 
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thus must traverse tlie object graph, pulling it apart, and ultimately must call upon the JVM. Traditional 
serialization and reflection mechanisms for storing and moving Java objects are just not practical for all types of 
devices, especially thinner devices. Some of the difficulties with Java reflection and serialization are that an 
object's graph (an object's h^sitive closure) reflection is difficult to do outside the JVM. Serialization is too large, 
5 requiring a large amount of code. In addition, serialization is a Java specific object interchange format and thus may 
not be used with non- Java devices. 

The Jini distributed computing model requires the movement of Java objects between Java devices. Thus, 
the serialization mechanism itself is not platform independent since it may not be used by non-Java platfonns to 
send and receive objects. Serialization is a homogenous object format - it only works on Java platforms. 
10 Serialization uses the reflection API and may be limited by security concerns, which oflen must be addressed using 
native JVM dependent methods. The reflection API may provide a graph of objects, but is inefficient due to the 
number of calls between the JVM and the code calling the reflection methods. 

The use of Java reflection to seriaUze an object requires an application to ping pong in and out of the JVM 
to pick apart an object one field at a time as the transitive closure of the object is dynamically analyzed, 
15 Deserializing an object usmg Java deserializadon requires the application to work closely widi the JVM to 
reconstimte the object one field at a time as the transitive closure of the object is dynamicaUy analyzed. Thus, Java 
serialization/deserialization is slow and cumbersome while also requiring large amounts of apphcation and JVM 
code as well as persistent storage space. 

Even for fliin clients that do support Java, the Jini RMI may not be practical for thm clients with minimal 
20 memory footprints and mmimal bandwidth. The serialization associated wdth the Jini RMI is slow, big, requires the 
JVM reflection API, and is a Java specific object representation, Java deserialization is also slow, big and requires 
a scrialized-object parser. Even Java based thin cUents may not be able to accept huge Java objects (along with 
needed classes) being retumed (necessarily) across the network to the client as required in Jmi. A more scalable 
distributed computing mechanism is needed It may be desnable for a more scalable distributed computing 
25 mechanism to address security concerns and be expandable to allow for the passing of objects, such as Java objects, 
and even to allow for process migration from one network mode to another. 

Object based distributed computing systems need persistent storage. However, as discussed above, 
attempts at object storage are often language and operating system specific. In addition, these object storage 
systems are too complicated to be used with many small, embedded systems. For example, the Jmi technology uses 
30 JavaSpaces as persistent object containers. However, a JavaSpace can only store Java objects and cannot be 
implemented m smaU devices. Each object in a JavaSpace is serialized and p^s the above-described penalties 
associated with Java serialization. It may be desirable to have a heterogeneous object repository for distributed 
computing that may scale from small to large devices. 

JavaSpaces from Sun Microsystems, Inc., draws from the parallel processmg woik of David Gelemter, a 
35 computer science professor at Yale University. Gelemter's set of fimctions named "Linda" create a shared memory 
space called a TupleSpace, in wMdi results of a computer's processes or the processes themselves ma^ 

access by multiple CPUs. Lmda therefore provides a global shared memory for multiple processors, 

Anotiier technology which extends Linda is TSpaces from IBM Corporation. TSpaces extends the basic 
Linda TupleSpace framework with real data management and the ability to download new data types and new 
40 semantic fimctionality. TSpaces provides a set of network communication buffers and a set of APIs for accessmg 
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those buffers. Like many of the solutions discussed above, TSpaces therefore uses a code-centric programming 
model and shares the drawbacks of such a model. Additionally, TSpaces is implemented m the Java programming 
language and therefore requu-es a Java Virtual Machine or other means of executing Java bytecode, such as a Java- 
capable microprocessor. Therefore, TSpaces may be inappropriate for small-footprint demes which cannot devote 
5 sufficient resources for executing Java bytecode. 

It is desirable in object oriented distributed systems to be able to locate object repositories and find 
particular objects witiiin those repositories. As mentioned above, the Jini look-up server may not be practical for 
small devices with small memory footprints. A more efficient mechanism for locating object stores may be 
desirable. 

10 It may be desirable in a distributed network computing model for clients to have the ability to locate 

services. Current network protocols eitiier provide only a single standard service access interface that provides no 
security when accessing a network service or provides ''all or nodun^' access to the full range of the service's 
capabilities, which may include administrator or privileged functions. Also, current network protocols to locate 
services do not provide a flexible mechanism for finding services. Current protocols either do not provide any 

1 5 selective search capability at all (e.g. UPnP) or only provide a primitive keyword and attribute grammar mechanism 
(e.g. SLP), Thus, current service discovery mechanism may be too inflexible in their security and search criteria 
mechanisms. 

Also, current service discovery models have a symmetric model for service location. However, it may be a 
waste of resources for certain service devices, such as devices whose functionality is available on a proximity basis, 
20 to support the discovery model This is because such devices are akeady located by proximity (e.g. one device 
physically pointing to another one). Thus, an alternate light-weight discovery mechanism may also be desirable for 
such devices. 

Distributed object access also desires a fair and efQcient sharing mechanism. As described above Jini 
currently uses a leasing mechanism to share objects. However, Jmi leases are time based which may result in a 

25 number of problems. For example, the current object holder might have no idea how long to lease an object and 
may hold it too long. In addition, the use of time-based leases may require that time be synchronized between 
multiple machines. Moreover time based leasmg may require operating system support In addition, Jini leases are 
established and released via RMI. Thus, the Jini leasing mechanism suffers from the above-noted problems with 
using RMI. In addition, the Jini leasing mechanism does not provide a security mechanism for establishing, 

30 renewing and canceling of leases. Other leasmg mechanisms may be desirable. 

Generally speaking, it is desirable for small memory foot print mobile client devices to be able to run a 
variety of services, both legacy and new, in a distributed envhx)nment The types of small clients may include cell 
phones and PDA's with a variety of different networking interfaces, typically low bandwidth. Often these devices 
have very small displays with limited jgraphics, but fliey could include laptops and notebook computers, which may 

35 have a larger display and more sophisticated graphics capabilities. The services may be a wide range of applit^ons 
as well as control programs for devices such as printers. It is desirable for a mobile client to be able to use tiiese 
services \^erever Ihey may be. 

A mobile cMent will often be at a temporary dynamic network address, so networking messages it sends 
cannot be routed beyond tiiat networicing interface (otherwise there may be collisions when two different clients on 

40 different networks have the same dynamic address). MobHe cHents often do not have the capabitity for a fiiU 
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fimction browser or other sophisticated software. The displays may limit the cUent from miming certain 
appKcations. Traditional appUcation models are based on predetermined user inter&ce or data 

change to the application requires recompilation of the application. 

It may be desirable for such clients to have a mechanism for findmg and mvoldng distributed applications 
5 or services. The client may need to run even large legacy applications which could not possibly fit in the client's 
memory footprmt As discussed above, current technology, such as Jini, may not be practical for small footprint 
devices. The pervasiveness of mobDe thin cUents may also raise additional needs. For example, it may be desirable 
to locate services based on the physical location of the user and his mobfle client For example, information about 
the services in a local vicinity may be very help&l, such as local restaurants, weather, traffic maps and movie 
10 mformation. Similarly, Moimation about computing resources, such as printers in a particrfar locati^^ 

helpM. Current technologies do not provide an automatic mechanism for locating services based on physical 
location of the cUent Another need raised by thin mobile cUents is that of addressing the human factor. Tim 
mobUe clients typically do not contain ergonomic keyboards and monitors. Tlie provision of such human fector 
services and/or the abiUty to locate such services in a distn^uted computing environment may be dw^ 
15 A distributed computing model should provide clients with a way to find transient documents and services. 

It may be desirable to have a mechanism for findmg general-pmpose documents (including services and/or service 
advertisements), where the docmnents are expressed in a platform-independent and language-mdependent typing 
such as that provided by extensible Markup I^age (XML). Current approaches, includmg lool^ 
for Jini, Universal Plug and Play (UPnP). and the Service Location Protocol (SLP), do not support such a general- 
20 purpose document lookup mechanism. For example, the Jini lookup mechanism is Ihnited to Java Language typing 
and is therefore not language-independent UPnP and SLP support a discovery protocol only for services, not for 
generd-purpose documents. 

SUMMARY 

In a distributed computing enviromnent, a service discovery protocol may allow cUents to search for 
25 services (both space services and specific services or types of services). Service providers (or a listener agent) may 
respond to search requests by publishing or providmg coiresponding advertisements or URIs to corresponding 
advertisements, men a service provider responds to a discovery search request (either directly or through a lisb^ 
agent), the provider may choose to pubUsh a protected or an un-protected (complete) advertisement A protected 
advertisement may include the set of information necessary to obtain a complete advertisement Publishing a 
30 protected advertisement, forces the cUent to the obtain a valid credential from an authentication service before 
receiving the complete un-protected advertisement from the service provider. A complete un-protected 
advertisement is needed to create a gate, and therefore to use the service. Forcing clients to obtain a vaUd credential 
beforeieceivinganadvertisementmayprovideanadditionallevelofsecurityfortheservicepr^^^ Thesecurity 
credentid that must be obtained to receive the complete advertisement may be the same security credential 
35 used to construct a gate to communicate with the service where the gate embeds the security credential m each 
message to the service. 

To obtain a complete advertisement given a protected advertisement a client obtains a capability 
credential from the specified authentication service by sending a credential request message. The credential request 
message may be sent to an anthenticated service URI specified in the advertisement for the service the client desires 
40 to access. When tiie client's request is received, a capability credential is generated. The capability credential may 
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be generated according to capabilities requested by the client and/orihe client's level of authorization. Hie cUent 
then receives the capability credential in response to its request The response may contain the credential needed to 
generate the complete advertisement This credential may be the same credential that the client's gate inchides in 
each message sent to the service. If the advertisement was a protected advertisement, the client then may send an 
5 advertisement request message containing the capability credential and an identification (e.g. UUID) of the service 
to the second URI specified in the protected advertisement The cUent then receives a complete advertisement ITie 
response to this second message is the complete advertisement of the specified service. THe complete advertisement 
and the capability credential may then be used to create a gate used to communicate with the service. 

In one embodiment, a method for accessing a service in a distributed computing environment may include a 
10 client locating a first service within the distributed computing enviromnent To locate services, the client may send 
a search message in a data representational language. Hie search message may mclude search criteria, such as 
service name and service type criteria. Services or a listener agent receiving the search message may compare the 
search criteria to service advertisements to find advertisements that match the search criteria. Service 
advertisements may be data representational language documents that provide access infonnation for corresponding 
15 services. Ite cUent may then receive search response messages which mdicate advertisements that matched the 
search criteria. 

The client may then select a service that is desired to be accessed and request a capability credential to 
allow the cUent to access some or all of that services capabilities. The client may send a capability credential 
request message to a URI specified in the selected service advertisement Tte URI may be for an authentication 
service. If the advertisement was a complete advertisement including schema information for messages to access the 
service, then the cUent may receive a capabiUty credential for accessing the services complete capabilities. If the 
advertisement was a protected advertisement ^ich does not include access schema information, then the client may 
include within its capability credential request message an indication of a set of desired capabiUties for which it 
desires permission to access from the service. 

A client then receives the capability credential which indicates that the client is aUowed to access at least a 
portion of the services capabilities. The capabiUties for which the cUent is aUowed access maybe fte lesser of the 
set of capabiUties which the client requested in its capability credential request message and the set of capabilities 
for which the cheat is authorized. If the original advertisement indicated in the response to the cUents search 
message was not a complete advertisement, the client then uses the capability credential to request a complete 
advertisement for its granted capabiMties. The cKent may send a advertisement request message to a URI specified 
in the protected advertisement A service provider receivmg the advertisement request message may generate a 
custom complete advertisement for the capabihties indicated by the cUents capability credential and return this 
complete advertisement to the cUent The cUent may then construct a message gate based on the complete 
advertisement for sending messages according to the schema in the complete advertisement to access the services 
35 capabilities. Hie gate may inchide the capabUity credential in each message so that its messages may be 
authenticated by the service. 

BRIEF DESgtTPTTON OF T HE DRAWINGS 

Figure lis an iUustration of a conventional distributed computing technology stack; 
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Figure 2 is an illustration of a distributed computing environment programming model according to one 
embodiment; 

Figure 3 is an iUustration of messaging and networking layers for a distributed computing environment 
according to one embodiment; 

5 Figure 4 is an illustration of a discovery service for finding spaces advertising objects or services in a 

distributed computing environment according to one embodiment; 

Figure 5 illustrates client profiles supporting static and formatted messages for a distributed computing 
environment according to one embodiment; 

Figure 6 is an illustration of a distributed computing model employing XML messaging according to one 
10 embodiment; 

Figure 7 iUustrates a platform independent distributing computing enviromnent according to one 
embodiment 

Figure 8 is an illustration of a distributed computing model in which services are advertised in spaces 
according to one embodmaent; 

15 Figure 9 is an illustration of a distributed computmg model in which results are stored in spaces according 

to one embodiment; 

Figure 10 is an illustration of cUent and service gates as messaging endpoints in a distributed computing 
model according to one embodiment; 

Figure 10b is an illustration a message endpomt generation according to a schema for accessing a service 
20 according to one embodiment 

Figure 1 1 a illustrates gate creation in a distributed computing environment according to one embodiment; 
Figure 1 lb illustrates gate creation and gate pairs in a distributed computing environment according to one 
embodiment; 

Figure 12 is an illustration of possible gate components in a distributed computing enviromnent accordmg 
25 to one embodiment; 

Figure 13 is an illustration of prox/ client for a conventional browser to participate in the distributed 
computiag envirormient according to one embodiment. 

Figure 14 iUustrates the use of a method gate to provide a remote method invocation interface to a service 
in a distributed computing environment according to one embodiment; 
30 Figure 15 is an illustration of the use of a space in a distributed computing environment according to one 

embodiment; 

Fi^e 16 illustrates advertisement structure according to one embodiment; 

Figure 17 illustrates one example of advertisement state transitions that an advertisement may undergo 
during its lifetime according to one embodiment; 
35 Figure 18 is an illustration various space location mechanisms m a distributed computing envkonment 

according to one embodiment; 

Figure 19 is an iUustration of space federations in a distributed computing environment according to one 

embodiment 

' Figure 20 is a flow diagram iUustrating client formation of a session with a space service in a distributed 
40 computing environment accordiog to one embodiment; 
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Figure 21 is an illustration of a space event type hierarchy for one embodime^ 

Figure 22 is a flow diagram Ulustrating service instantiation in a distributed computing environment 
according to one embodiment; 

Figure 23 is an illustration of a default space in a distributed computing environment according to one 

5 embodiment; 

Figure 24 illustrates an example of a device brid^g proximity-based devices onto another transport 
mechanism to allow the services provided by the proximity-based de 
proximity range of the devices, according to one embodiment; 

Figure 25 is an illustration of the use of lease renewal messages in a distributed computing envkonment 

10 according to one embodiment; 

Figure 26a is a flow diagram iUustrating an authentication service providing an authenti 

a cheat according to one embodiment; 

Figure 26b is a flow diagram expanding on step 1002 of Figure 26a and illustrating an authentication 
service generating an authentication credential accordmg to one embodhnent; 
15 Figure 27 illustrates one embodiment ofa bridging mechanism; 

Figure 28 illustrates an example of a space discovery protocol mapped to an external discovery service 

according to one embodiment; 

Figure 29 illustrates bridging a client external to the distributed computing environment to a space in the 
distributed computmg environment according to one embodiment; 
20 FigureSOisaniUustrationofaproxymechanismaccordingtooneembodiment; 

Figure 3 1 iUustrates one embodiment of a client with an associated display and display service accordmg to 
one embodiment; 

Figures 32A and 32B illustrate examples of using schemas of dynamic display objects according to one 
embodiment; 

25 Figure 33A illustrates a typical string representation in the Cprograniminglang^ 

Figure 33B iUustrates an exanq)le of aconventional string fimction; 

Figmre 33C iUustrates an efficient metiiod for representing and managing strings in general, and in smaU 
footprint systems such as embedded systems m particular according to one embodiment; 

Figure 34 mustrafces a process of moving objects between a cUent and a service according to one 
30 embodiment, 

Figures 35a and 35b are data flow diagrams illustrating embodiments where a virtual machine (e.g. JVM) 
includes extensions for compihng objects (e.g. Java Objects) into XML representations of the objects, and for 
decompilmg XML representations of (Java) objects into (Java) objects; 

Figure 36 iUustrates a cHent and a service accessing store mechanisms in the distributed computing 
35 environment, according to one embodiment; 

Figure 37 iUustrates process migration usmg an XML representation of the state of a process, according to 

one embodiment; 

Figure 38 iUusti^tes a mobUe client device accessing spaces in a local distributed computing network, 
accordingto one embodmient; 
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Figure 39a illustrates a user of a mobUe device discovering the location of docking stations, according to 
one embodiment; 

Figure 39b illustrates a mobile client device connecting to a docking station, according to one embodiment; 

Figure 40a Ulustrates an embodiment of embedded devices controlled by a control system and accessible 
5 within ti^ie distributed computing environment, according to one embodiment; 

Figure 40b illustrates a device control system connected via a network (e.g. the Internet) to embedded 
devices accessible within the distributed computing environment, according to one embodiment; 

Figure 41 is a flow chart illustratmg service discovery according to one embodiment; 

Figure 42 is a flow chart illustratmg an example of locating service advertisements according to one 
10 embodiment; 

Figure 43 is an illustration compares the difference in the discover process when the published 
advertisement is a complete advertisement versus a protected advertisement, according to one embodim^^ 

Figure 44 is a block diagram of an example of a system in which a cUent device directly discovers a service 
on a service device over a proximity link, according to one embodhnent; and 
15 Figure 45 is a basic flow diagram Ulustrating cUent discovery of a proximity service, accordmg to one 

embodiment. 

While the invention is susceptible to various modifications and alternative forms, specific embodmients 
thereof are shown by way of example in the drawings and will herein be described m detail. It should be 
understood, however, that the drawmgs and detailed description thereto are not intended to limit the mvention to the 
20 particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives 
falling within the spuit and scope of the present mvention. 

PETAILEP DESCRIPTION OF EMBODIMENTS OF THE INVENTION 

25 Overview of Embodiments for Distributed Computmg 

Turning now to Figure 2, a distributed computing envnonment programming model is illustrated The 
model includes API layer 102 for facilitating distributed computing. The API layer 102 provides an interface that 
facilitates cUents connecting to services. Hie API layer 102 is concerned with the discovery of and the connecting 
of cUents and services. The API layer 102 provides send message and receive message capabi^^^^ 
30 API may provide an interface for simple messages in a representation data or meta-data format, such as in the 
extensible Mark-up Language (XML). Note that while embodiments are described herein employing XML, other 
meta-data type languages or formats may be used in alternate embodhnents. In some embodiments, the API layer 
may also provide an interface for messages to communicate between objects or pass objects, such as Java objects, 
API's may be provided to discover an object repository or ^'space^ find a particul^ 
35 object, and write or take an object to or from the object repository. Objects accessible through API layer 102 may 
be represented by a representation data format, such as XML. Thus, an XML representation of an object may be 
manipulated, as opposed to the object itself. 

API layer 102 sits on top of a messagmg layer 104. The messagmg layer 104 is based on a representation 
* • data format, such as XML. hi one embodiment, XML messages are generated by messaging layer 104 according to 
40 calls to the API layer 102. The messa^g layer 104 may provide defined static messages that may be sent between 
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clients and services. Messaging layer 104 may also provide for dynamically generated messages. In one 
embodiment, an object, such as a Java object, may be dynamically converted into an XML representation. The 

messaging layer 104 may then send the XML object representation as a message. Conversely, the messaging layer 
104 mayreceive an XML representation of an object The object may then be reconstituted from that message. 

5 . In one embodiment, messages sent by messaging layer 104 may include several basic elements, such as an 

address, authentication credentials, security tokens, and a message botfy. The message system transmission and 
receive mechanisms may be completely stateless. Any notion of state may be embedded in the message stream 
between sender and receiver. Thus, message transmission may be done asynchronously. In a preferred 
embodiment, no coraiection model is imposed. Thus, transports such as TCP are not required. Also, error 

10 conditions may be limited to non-deliveiy or secmity exceptions. 

Messaging layer 104 sits on top of a message capable networidmg kyer 106. In a preferred embodiment, 

messaging layer 104 does not require that a particular networking protocol be used. TCP/IP and UDP/IP are 
examples of message capable protocols that may be used for message capable networking layer 106; However, 
other more specialized protocols such as the Wireless Application Protocol (WAP) may also be used. Other 
15 possible message protocols are IrDA and Bluetooth network drivers beneath the transport layer. Networidng layer 
106 is not limited to a smgle reliable comiection protocol, such as TCP/IP. Therefore, comiection to a larger variety 
of devices is possible. 

In one embodiment, message capable network layer 106 may be implemented fiom the networking classes 
provided by the Java2 Micro Edition (J2ME) platform. Tlie Java2 Micro Edition platform may be suitable for 
20 smaller footprint devices that do not have the resources for a foil Java platform or in which it would not be efficient 
to run a foil Java platform. Since J2ME akeady provides a message capable family of networking protocols (to 
support sockets), it foUows that for the small footprint cost of adding messaging layer 104, distributing computing 
fecilities may be provided for small devices that abeady include J2MB. 

Message capable networkmg layer 106 may also be provided by the Java Development Kit's (JDK) 
25 javajiet networking classes. Alternatively, any message capable networkmg fecilities may be used for message 
capable networkmg layer 106. to a prefeiied embodiment, a reUable transport is not required, thus embedded 
devices supporting an umeliable data gram transport such as UDP/IP may still suppo^ 

Thus, thin cUents may participate in a distributed computing environment by sunply addmg a Ihm 
messaging layer 104 above a basic networkmg protocol stack. As shown in Figure 3, a basic system inchides 
30 messagingkyer 104 on top of a networidng layer 106. The networking layer may provide for rehable messages, 
e.g. TCP, or unreUablc messages, eg. UDP. The Internet Protocol (IP) is show in Figure 3 as an example of 
protocol that may be used in networking layer 106. However, the distributed computing enviromnent does not 
require IP. Other protocols xm be used in fte distributed computing environment besides IP. A network driver 
such as for Ethernet, Token Ring. Bluetooth, etc. may also be part of the networking la^^^^ Many small clients 
35 ah^ady provide a network driver and transport protocol such as UDP/IP. TTins, with the addition of the thin XML 
based messa^g layer, the device may participate m the distributed computing environment. 

Thus, the foundation for the distributed computmg environment is a simple message passmg layor 
implemented on top ofreUable connection and/orunreliable data grams. The messaging technology is very different 
from communications technologies employed m other distribution computing systems, such as Tmi which employs 
40 the Java remote method invocation (RMI). The message passing layer 104 supports an asynchronous, stateless slyle 
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of distributed programming; instead of the sync^^ Moreover, message 

passing layer 104 is based on a data representation language such as XML and thus copies data, but not code, from 
source to destination, unlike RMI. By using a representation data language, such as XML, messaging layer 104 may 
interoperate with non-Java and non-Jini platforms in a seamless fashion because Java code is not assumed on the 
5 sending or receiving end of a message. Moreover, unlike RMI, messaging layer 104 does not require a reHable 
transport mechanism such as TCP/IP- 

The message passmg layer may provide sunple sendQ and receiveQ methods to send a message specified as 
an array or string of bytes, for example. Hie sendQ method may return immediately, perfoimmg the data transfer 
asynchronously. For flow control purposes a callback method may be suppHed which is mvoked m Hie event that 
10 the sendO method throws an exception indicatmg it cannot handle the sendQ request The receiveQ method may be 
synchronous and may return the next available message. 

The message passmg layer may also provide methods for storing XML representations of objects, services 
and content m "spaces". A space is named and accessed on the network using an URI (Uniform Resource 
Identifier), The URI may be a XJRL (Uniform Resource Locator) or a simpler version of a URL. In some 
15 embodunents, the URL class may be too large. For such embodiments a simpler resource locator may be used that 
specifies the protocol for moving the messages between client and server, protocol dependent host ID, protocol 
depeiident port EO, and a space name. 

An XML representation of an object may be added to a space using a writeQ method provided by tiie 
messagmg layer. In one embodmient, the object and the client-specified name may be supplied as parameters. In 
20 one embodiment, the write method may translate the object into its XML representation. A tak^ 

provided to return tiie object and remove it from the space. A ^dQ method may be provided to return a specified 
object fi-om its XML representation in a space. The findQ method may also be used to return an array of matching 
objects m a space given a class. Each of these space methods is implemented using tiie message-passing layer. A 
lease mechanism may also be provided, as described in more detail below. 
25 A discovery service may be provided for clients as a general search fecility that may be used by a client to 

locate a particular space. Rather than attempt to define a complicated search prot^ocol which may not be feasible for 
a thin client to implement, the discovery service may offload the actual search to XML-based search facUities, 
leavmg the discovery service simply to provide interfece fimctionaHty to the client The approach is iUustrated in 
Figure 4. In one embodiment, the discovery service receives a string specifying something to locate, and it sends an 
30 XML message to a known discovery front-end (perhaps found in a defeult space), which then parses the string and 
makes a corresponding XML query to a search facihty(wMch may be an intemet search facili^^^ The discovery 
front-end may parse what it obtains from the search fecihty and repackage it as an array of strings (each string may 
be a URI for each found space) which it may send in an XML message to the cUent It should be noted that the 
discovery service does not require that the messaging be atop a connection-oriented transport Thus, even very thin 
35 chents that do not have TCP could use such a discovery service. The discovery front-end makes it possible for the 
client to discover spaces without a browser or search feciHty on the cUent The client only needs a simple fecihly 
that sends a string that specifies keywords to the front-end, yMch interfeces with a search facility. 

A client may be any platform that caa send a message using at least a subset of the API and messaging 
layers. In one embodiment the API layer may provide for both static (or raw) and formatted (or cooked) messages. 
40 A server may be any platform capable of receiving and Mfillmg message requests. An expUcit raw message send 
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may be provided that moves a series of bytes from a client to a server or to another client The message type may be 
specified as reliable (e.g. TCP) or mireliable (e.g. UDP). The smallest of devices may use raw unreliable message 
passing as their sole means of participation in the distributed computing environment The device may use these 
messages to annoimce its presence and its status. Such small devices may also receive raw messages to implement 
certain functions, such as turmng a feature on or off. 

Message-based services such as spaces may send and receive reliable formatted messages. A space 
message may be formatted with a well-defined header and with XML. In one embodiment, a formatted message 
send may occur when a client uses a space method to claim, write, or take objects from a space. The message 
contents may be dynamically formatted m XML and contam well-defined headers. Figure 5 illustrates client profiles 
supportmg formatted and static messages. By using static messages, small devices may use a smaller profile of code 
to participate in the distributed computing environment For example, a small device could just send basic 
pre-defined messages. Depending on &e client, the static pre-defined messages may consume a small amount of 
memory (e.g. <200 bytes). Static messages may also be an option even for larger devices. On the other hand, the 
dynamic XML messages may be useful when object values are not known at compile time. 

Turning now to Figure 6, a distributed computing model is illustrated that combines a messaging Vstem 
with XML messages and XML object representation. The platform independence of XML may be leveraged so that 
the system may provide for a heterogeneous distributed computing environment Thus, chent 110 may he 
implemented on ahnost any platform instead of a particular platform like Java. The messaging system may be 
implemented on any networic capable messaging layer, such as Intemet protocols (e.g. TCP/IP or UDP/IP). Thus, 
the computing environment may be distributed over the hitemet In one embodiment, the messaging system may 
also use shared memory as a quick interprocess message passing mechanism when the client and/or space server 
and/or service are on the same computer system. The distributed computing model of Figure 6 may also be very 
scalable because ahnost any size client can be configured to send and/or receive XML messages. 

As shown in Figure 6, two kmds of software programs may run in fee distributed computing model: 
services 112 and clients 110. Services 1 12 may advertise thek capabilities to cHents wishmg to use the service. The 
services 112 may advertise their capabilities in spaces 114. As illustrated in Figure 7, clients 110 and services 112 
may or may not reside withm the same networic device. For example, devices 120 and 124 each support one client, 
whereas service 1 12a and client 1 10b are implemented m the same device 122. Also, as illustrated m Figure 7, no 
particular platform is reqmred for the devices to support the cUents and services. For example, device 120 is Java 
based, whereas device 124 provides a native code runthne environment 

A device may be a networking transport addressable unit Example devices include, but by no means are 
limited to: PDAs, cellular/mobile phones, notebook computers, laptops, desktop computers, more powerful 
computer systems, even supercomputers. Botii cUents and services may be URI-addressable instances of software 
(or firmware) that run on devices. Usmg the distributed computing envn-onment architecture, a client may run a 
service. A space is a service that manages a repository of XML documents. Even though it is redimd^t, tiie term, 
^ace service, may be used herein for readability. A software component may be both a client and service at 
different tunes. For example, when a service uses a space (e.g. to advertise itself ), that service is a client of the 

space. . 

Figure 8 illustrates the basic model of the distributed computing environment m one embodhnent The 
distributed computing environment may connect clients 110 to services 112 throughout a network. The network 
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may be a wide area network such as the Internet The network may also be a combination of networks such as a 
local area network (LAN) connected to a wireless network over the Internet As shown in Figure 8, a service 112 
publishes an advertisement 132 for itself (represented in XML) in a space 114. The advertisement 132 specifies the 
service's XML schema and URI address. Then, a cHent 110 may look up the advertisement 132, The client 110 
may use the advertisement 132 to instantiate a gate 130. The gate 130 allows the client 110 to run the service 1 12, 
by sendmg (and receiving) XML messages to (and from) the service 112. 

Some results of running a service may be returaed to the client in an XML message. However, smce other 
results maybe too large for a small client to receive and consume at once, a service 112 may put those results or an 
XML representation of the results 134 in a space 114, as shown in Figure 9, and return Ihem by reference (in an 
XML message) to the chent 110, rather than by value. Examples of methods of retummg a reference to results 
include, but are not limited to: returning in the message a XJRl referencmg the results in a space, and: retummg m tiie 
message an XML document includmg die URI of the results. Later, the client 110 may access the results, or pass 
them by reference to ano&er service. The space m which results may be stored may be difierent from the space in 
which tiie service is advertised. 

In one embodiment, the distributed computmg enviroimient uses XML for content definition, advertisement 
and description. Kew content for the distributed computing envhronment (messages and advertisements for 
example) are defined in XML. Existing content types (e.g. developed for other envhonments) may also be 
described using XML as a level of indirection (meta-data). XML provides a powerful means of representing data 
throughout a distributed system because, similar to the way tfiat Java provides universal code, XML provides 
universal data. XML is language agnostic and is self-describing. The XML content may be strongly typed and 
vaUdated using schemas. Usmg a provided XML schema, the system may ensure that only valid XML content is 
passed in a message, XML content may also be translated, into other content types such as HTML and WML, 
Thus, cUents that do not understand XML may still use the distributed computing environment services. 

In one embodiment, the distributed computing environment messages may define the protocol used to 
connect clients with services, and to address content in spaces and stores. The use of messages to define a protocol 
allows many different kinds of devices to participate in the protocol Each device may be free to implement die 
protocol in a manner best suited to its abihties and role. For example, not all devices are capable of supporting a 
Java runtime environment The distributed computing envhonment protocol definition does not requke nor imply 
the use of Java on a device. Nor does it preclude it 

A service's capabilities may be expressed in terms of the messages the service accepts. A service's message 
set may be defibed usmg an XML schema. An XML message schema defines each message format using XML 
typed tags, Tlie tag usage rules may also be defined in the schema. The message schema may be a component of an 
XML advertisement along widi the service's message endpoint used to receive messages. The distributed computing 
environment may allow clients to use aU or some subset of a service's capabilities. Security policies may be 
employed to enforce die set of capabiUties given to a cHent. For example, once asetof capabiUties has been^ven 
to a client, the client may not change that set without proper audiorization. This model of capability definition 
allows for services levels that range from a base set of capabiUties to an extended set Extensions may be added to 
services by addmg to the number of recognized messages. 

In one embodiment, all operations m the distributed computing environment are embodied as XML 
messages sent between clients and services. Storage (both transient and persistent) providers are examples of 
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services that enable clients and services to store, advertise, and address content Clients and services may find each 
other and broker content using a transient storage space. Services may place a content or service advertisement in a . 
space. The advertisement may describe the content type or the capabilities of the service. Clients may subsequently 
browse spaces looking for advertisements that match a desired set of capabilities. When a client finds a matching 
5 advertisement, a communication channel may be established which may enable bi-directional message passing to the 
service backing the advertisement, hi one embodiment, the communication channel is authenticated. Results (v^^hich 
are just another content type) from service operations may be returned directly to the client in a response message, 
advertised and stored in a space, or advertised in a space, but stored persistently. Stored results may be addressed 
using a URI (e.g. returned m the response message) and may have an associated authentication credential. 

10 

Message Gates 

As discussed above, the distributed computing environment leverages off the use of a data description 
language, such as XML. XML be used to describe a target entity (e.g. document, service, or client) to an extent 
such tiiat code may be generated to access that entity. The generated code for accessinjg the target entity may be 
15 refeired to as a message gate. Thus, in one embodiment, the distributed computing environment differs from other 
distributed computing environments in that instead of passing the necessary code between objects necessary to 
access the other object, the environment provides access to XML descriptions of an object or target so that code 
may be generated based on the XML description to access the target The distributed computing environment may 
use an XML schema to ensure type safety as well as a programming model (e.g. supported messages) without having 
20 to agree upon language specific APIs, just XML schemas. 

Code generated from an XML schema may also incorporate the language, security, type safety, and 
execution environment characteristics of the local platform. The local platfomi may thus have control over the 
generated code to ensure that it is bug-free and produces only valid data according to the schema. The generated 
code may conform to the client's code execution environment (e.g. Java, C-H-, Smalltalk), as well as its management 
25 and security framework (Web-server and/or operating system). 

Note that the distributed computing environment does not require that code generated from an XML 
schema be generated "on the fly" at runtime. Instead, some or all of the code may be pre-generated for categories 
(or classes) of services, and then linked-in during the platfonn buOd process. Pre-generation of code may be useM 
for some clients, such as embedded devices, where certain XML schemas are already known, hi one embodiment, 
30 some or all of the code doesa*t actually have to be generated at alL A private code-loading scheme (within the 
client) might be used in one embodiment to augment die generation process. In addition, the distributed computing 
environment m^ specify, in some embodiments, an interfece to dowidoad code for additional features in accessing 
a service (see, e.g., message conductors described below). Typically, such downloaded code may be small and the 
client may have the option to download the code or not 
35 The phrase "generated code" may refer to code that originates wifliin the client under the control of the 

chent code execution environment, or to code that is gener^ed elsev^ere (such as on the service system or on a 
space service system) and that m^ be downloaded to the chent system after generatioiL Binding time, however, 
may be at runtime. At runtime, the generated code may be bound to a service address (URT), so that a message may 
be sent to that service instance. 
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As discussed above, the interface to any service in the distributed computing environment may be specified 
by an XML schema, defining the set of messages that a client may send (and receive from) that service. As 
illustrated in Figure 10, the client 1 10 and service 1 12 may each construct a message gate 130 for communicating 
according to the specified XML schema. From the XML schema advertised for the service 1 12 (and possibly other 

5 information in the service advertisement), a message gate 130a or 130b may be constructed by the client 110a or 
1 1 Ob respectively- A corresponding message gate 1 3 Oc generated from the same XML schema may also exist on the 
service 112a. A gate 130 is a message endpomt that may send and/or receive type-safe XML messages, and that 
may verify the type correctness of XML messages when sending and/or receiving the messages. The message gate 
may also provide for authentication and/or other security mechanisms to ensure that the message endpoint is secure. 

10 . In one embodunent, message gates arc always secure. 

The distributed corcputing environment messaging layer described above may be coupled to or may be part 
of die gate. The messaging layer asynchronously delivers an ordered sequence of bytes, using a networidng 
transport, from the sender to the receiver, maintaining the notion on both the sender and receiver that this sequence 
of bytes is one atomic unit, the message. The distributed computing enviromnent does not assume that the 

15 networking transport is IP-based. Instead, the messaging layer may sit atop whatever networking transport layer is 
supported by the device. 

Message gates may provide a mechanism to send and receive XML messages between clients and services. 
The XML messages may be "typed". For example, the messages may include tags to indicate if a message data field 
is, e.g., integer, floating point, text data, etc. A message gate may be constructed to verify the type correctness of 

20 messages sent or received. A message gate also may authenticate (e.g. securely identify) the sender of a received 
message. An XML schema may be provided for a service that describes the set of messages accepted by the service 
and/or sent by the service. A message gate may verify the correctness of messages sent or received according to the 
XML scherna for which the gate is constructed. 

A gate may be constructed as a single atomic unit of code and data that performs type verification and/or 

25 message correctness verification and/or sender identification for messages between a client and a service in the 
distributed computing envfronment In one embodiment, once the atomic unit of code and data for a message gate 
has been created, it cannot be altered as to its typing, message descriptors, and sender identification. In another 
embodiment, the gate may be modified as to the contents of the message schema after the gate is created, including 
deleting, adding, or modifying messages in the message schema. 

30 A message gate is the message endpoint for a client or service in the distributed computing enviromnent A 

message gate may provide a secure message endpoint that sends and receives type-safe XML messages. Messages 
gates may allow clients and services to exchange XML messages in a secure and reliable fashion over any suitable 
message transport (e.g. HTTT). For a client, a message gate may represent the authority to use some or all of a 
service*s capabilities. Each capabihty inay be expressed in terms of a message that may be sent to a service. Each 

35 such message may be sent through a cHent message gate which may verify the correctness of tfre message. The 
message may be received by a service message gate which may authenticate the message and verify its coErectness. 

A message gate may provide a secure communication endpoint that type checks XML messages. As 
further discussed below, a message gate may also provide a inechanism to restrict the message flow between clients 
and services. In one embodiment when a client desires to access a service, a client and service message gate pair is 

40 created, if not akeady existing. In one embodiment, the service message gate may be created when Hie service 
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receives a first message from the clieat message gate. lu one embodiment, one or more service message gates may 
be created when the service is initialized, and may be used to pair with client message gates when created. The 
creation of a message gate may involve an authentication service that may negotiate the desired level of secm-ity and 
the set of messages that may be passed between client and service. In one embodunent, the authentication service 
may accept a client ED token (also referred to as a cUent token), a service ID token (also referred to as a service 
token), and a data representation language message schema that describes the set of data representation language 
messages that may be sent to or received from the service. For example, messages may be described that may be 
sent from a client to a service to mvoke the service or to hivoke aspects of the service. Messages may also be 
described that are to be sent from the service, snch as response messages and event notification messages. Refer to 
the Authentication and Security section below for a friither discussion of how the authentication service may be used 
in the construction and use of message gates. 

A client message gate and a service message gate pah may allow messages to be sent between the client 
and the service. In one embodiment, message gates may be created that only send and/or receive a subset of the 
total set of messages as described in the message schema for a service. This limited access may be used whhm the 
distributed computing envfronment to unplement a policy of least privilege whereby clients are only given access to 
specific mdividual message types, based on a security pohcy. Refer to the Authentication and Security section 
below for a fiuther discussion of security checks for gate usage and gate creation 

Client and service gates may perform the actual sendmg (and receivmg) of the messages from the client to 
the service, ushag the protocol specified in the service advertisement (URI of service m the service advertisement). 
The client may run the service via this message passing. A message gale may provide a level of abstraction between 
a client and a service. A client may access a service object through a message gate instead of accessing the service 
object dnectly. Smce the gate abstracts the service from the cUent, the service's code may not need to be loaded, 
and then started, until the client first uses the service. 

The chent gate may also perform verification of the message against the XML schema, or verification of 
the message agamst the XML schema may be performed by the service gate, e.g. if the chent indicates it has not yet 
been verified. In some embodiments, verification may not be practical for simple clients and may thus not be 
requfred at the client In some embodunents, verification may be performed by the service. The gates may also 
perform authentication enablement and/or security schemes. In one embodiment, if a client does not support the 
protocol specified in the service advertisement, then it may not be able to construct the right gate. To avoid this 
problem, service advertisements (used for gate construction) may include a list of possible URIs for a service, so a 
variety of clients may be supported. 

A basic message gate may implement an API to send and receive messages. The API moves data (e.g. 
XML messages) m and out of the gate, validating messages before sendmg and/ or upon receiving. In one 
embodunent, message gates may support a fixed minhnum API to send and receive messages. This API may be 
extended to other features as discussed below. As illustrated in Figure 10b, a gate 130 may be generated according 
to an XML schema 132. The generated gate code verifies messages based upon the XML schema. The gate may 
verify correct message types and/or content through the message API. As illustrated in Figure 10b, through the 
message API a verified message may be sent to a service. ITie message may be received by a corresponding gate at 
the service. In response to &e message, the serVice may generate results 180. The service may return result data 
182 through its gate. The results data may be the results themselves or a reference to the results, such as a URI to 
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results stored in a space.. In various embodiments, the message API may support synchronous messages (request- 
response), asynchronous messages (response is disconnected from request), unicast messages (point to point), multi- 
cast messages (broadcast), and publish and subscribe (event messages), for example. Other type of messages may 
also be supported, such as remote method invocation messages. 

Each message sent by a gate may include an authentication credential so that the receiving gate may 
authenticate the message. Each message may also include a token which includes information allowing the 
receiving gate to verify that the message has not been compromised or altered. For example, the sender may 
compute a hash or checksum ofthe message which may be verified by the receiver. The sender may also encrypt 
this token and/or the entire message ushig the sender's private key and inay include in the encrypted message the 
corresponding public key so that the receiver may verify that the token was not -changed. See the section below on 

Authentication and Security. 

A pair of message gates may provide a mechanism for commmiicating requests from cUenls to services and 

response from services to clients. Two associated message gate endporats may be used to create a secure atomic bi- 
directional message channel for request-response message passing. Thus, the distributed computmg environment 
15 may employ a message transport m which a message gate exists on both the client and the service sides. Tht two 
gates may woric togetber to provide a secure and reliable message channel. 

Turning now to Figure 11a, an illustration is provided for one embodunent showmg construction of a gate 
130a in a cUent 110 from a service advertisement or other service description 132. The cUent may have a gate 
factory 140 that is trusted code on the client for generating gates based on XML service descriptions. The use ofthe 
20 gate factory 140 may ensme that the gate it generates is also trusted code, and that the code is correct with respect to 
the service advertisement As shown in Figure lib, a gate 130c may also be constructed at a service 112. The client 
gate 130a and the service gate 130c provide message endpoints for communications between the cUent and service. 
In one embodiment, the pieces the gate fectoiy needs to construct a gate 130 are the XML schema of the service 
(from the service advertisement) and the URI of flie service (from the service advertisement). In anoflier 
25 embodiment, an authentication credential may also be obtained and used in gate constmction by running an 
authentication service specified in the service advertisement 

A gate factory may provide a trusted mechanism to create message gates. In some embodiments, m order 
to ensure that a message gate is a trusted message endpoint, the code used to create the gate must be trusted code. A 
gate fectory 140 may be a trusted package ofcodefliat is used to create gates. In one embodunent, each client and 
30 service device platform that desires to send and receive messages in the distributed computing environment may 
have a gate fectory. In some embodiments, gates may be pre-cohstructed by a separate gate factory so that a device 
with pre-constructed gates may not need a foil gate factory, or may include a partial gate factory for binding a 
service URI and/or an authentication credential to the pre-constructed gate at runtime (e.g. when messagmg is 
desired). 

35 A gate fectory for a device may generate gate code that may incorporate the language, security, type safety, 

and/or execution environment characteristics of the local device platfonn. By constructing gates itself a device has 
the ability to ensure that the generated gate code is bug-free, produces only valid data, and provides typ^safely. An 
advantage of a device generating its own gate code as opposed to downloading code for accessing a service is that 
the client code management environment has the controL The generated code may confonn to the client's code • 

40 execution enviromnent (e.g. Java, C-H-, SmaUtalk), as well as its management and security framework (Web-server 
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and/or operating system). Generated code is also trusted code, because the clienfs runtune environment was 
involved in its creation. Trusted security information therefore may also be added by the trusted generated code. 
Thns, a device may receive an XML message schema for a service and then construct a gate based on that schema to 
access the device. The XML schema may be viewed as definmg the contract with the service and the generated gate 
code as providing a secure way to execute die contract. Note that open devices, in which m-trusted (e.g. 
downloaded) code may be run, may be configured so that gates may be generated only by trusted code. Open 
devices may employ a process model in which gates are enclosed in a protected, isolated code container that is not 
accessible to tools, such as debuggers, capable of discovering the gate's implementation, especially tbe gates 
authentication credential. 

A gate factory 140 may negotiate on behalf of a client with a service to create a gate to send messages to 
the service, Sunilarly, a gate may be constructed at the service to receive messages from the client gate and send 
messages to the client gate. Together, the cHent and service gates may form a secure bi-directional communication 
channel. 

A gate fectory may provide a level of abstraction in gate creation. For exan^le, wlien a client desures to 
use a service, instead of the cUent directly creating a gate to access the service, die gate may be created by a gate 
factory as part of instantiating the service. 

The gate factory may create or may include its own trusted message gate that is used to communicate with 
an audientication service (e.g. specified by a service advertisement) to receive an authentication credential for the 
gate being constructed. For services that do not restrict access, a gate may be constructed without an authentication 
credential. The gates for such services may not need to send an authentication credential with each message smce 
the service does not restrict access. The authentication service is an example of a service that does not restrict 
access, in one erabodhnent. Thus, a gate factory may be configured to optimize gate constraction by checking 
whetixer a service restricts access. If the service does not restrict access, then die gate factory may avoid running an 
authentication service as part of gate construction and may avoid included provisions for an authentication 
credential as part of the constructed gate. The gate factory may also receive or download an XML message schema 
(e.g. specified by a service advertisement) to create a gate matching that schema. The gate factory may also 
receive or download a URI for the service and/or for a service message gate for use in creating tiie client message 
gate to communicate with the URI. 

In addition, another gate construction optimization may be employed for certain clients that do not desire to 
perform checking of messages against a service's XML schema. The client may be too tiiin to perform tiie checking 
or may rely on die service gate to perform tiie checking or may simply choose not to perform die checking (e.g, to 
reduce gate memory footprint). The gate fectoiy may be configured to receive an indication of whether or not a gate 
should be constructed to verify messages against tiie provided XML schema. In some embodiments, certain cUcnts 
may have a gate factory that does not provide for message verification against a schema for its constructed gates. In 
some embodiments, gates may be pre-constructed not to verify messages. In some embodiments, a gate may be 
constructed to verify outgoing messages only, or verify received messages only. Thus, m some embodunents, a 
client may avoid or may chose to avoid building some or all of the gate code tiiat checks tiie messages against tiie 

XML schema. * 

In some embodiments, devices may mamtain a cache of gates to avoid constmctmg them each time flie 
same service is run. For example, when a new gate is constructed by a gate factory, tiie gate may be maintained in a 
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gate cache. When the gate is no longer being used, it is kept m the gate cache mstead of being deleted If the gate 
cache becomes Ml, one or more gates may be removed from the gate cache according to a cache replacement 
algorithm, such as least recently used. When the gate factory is called to construct a gate, it first checks the gate 
cache to see if a matchmg gate akeady exists so that construction of a new gate may be avoided 
5 The building of a gate may be made lightweight by appropriate reuse of pieces used to construct other 

gates. Certam portions of each gate may be the same, and thus may be reused from gate to gate, such as parts of the 
message verification code. Also, for some devices, common gate code may bebuUt mto the system software for the 
device and shared by all gates on that device. Thus, the gate factory may avoid rebuildmg this common code for 
each gate, histead, the gate factory may simply bind the gate to this system software portion. For example, a system 
10 software portion may be provided to handle the message layer over whatever transports are provided on the device. 
Space services in particular may be good candidates for many of the gate construction optimizations 
described above since a service gate constnicted for a space service may perform many of the same functions as 
other service gates for that space service. Refer to the Spaces section below for more information on space serAices. 
In some instances, a more efficient form of method invocation may exist For example, if 
15 runs m the same Java Virtual Machine as the client application, a more efficient form of method invocation may be 
to create a Java dynamic proxy class for the service, hi such a case, a java.langjeflect.Method invocation may be 
faster than sending a message. A gate binding time procedure may check for such an opfimi2ation and use it instead 
of runnmg the gate factory to create a gate or bind an existmg gate. 

In one embodiment, such as for special-purpose clients or small embedded devices, the generation of gate 
20 code at runtime may not be desirable due to memory consumption and code generation time. Thus, mstead of 
having a gate factory that generates gates at runtime, in some embodiments gates may be pre-generated and built 
into the device. For example, message gates may be generated during the build of embedded software as a means of 
including a built-in secure message endpoint that does not have to be constmcted at runtime. Thus, a client with 
built-in gates may not need a full gate factory, or may require only a partial gate factory for performing certain 
25 runtime binding to a buUt-m gate, such as for the URI and/or authentication crede^^^ 

A generation tool may be provided for the pre-constmction of gates. The generation tool may include an 
XML parser, a code generator and a code compiler. In one embodhnent, the code generator may be a Java source 
code generator and tiie code compiler may be a Java code compfier. During the build of the software for which 
built-in message gates is desired, tiie generation tool is run with mput Jfrom aU die relevant XML sdhemas for which 
30 gates are desired 

As an example, if it is desired for a device to have a built-in message gate tirat can send and receive 
messages from a digital camera, the build of tiie device software may include running die gate generation tool mth 
the camera's XML message schema as input The XML schema may be parsed by the XML parser that may convert 
the XML schema mto an internal form suitable for quick access during a message verification process. Tlie tool's 

35 code generator may provide source code for a gate corresponding to the camera's schema. In some embodhnents, 
the generation tool may also compile the source code and the gate code may be linked mto die software package for 
fte device. At runtime, tiie camera service may be discovered in die distributed computing environment The 
message URI for tiie camera service may be bound to tiie built-in gate for the camera witiiin the device. The binding 
oftiieURItotiiepre-constructedgatemay be perfonned by a gate constructor wit^ This gate 

40 constmctor may be a much smaller, simpler gate fectory. When tiie camera service is instantiated, tiie URI for tiie 
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camera service is passed to the gate constructor as an XML message. The gate constructor may then bind the mi to 
the pre-constructed gate. 

Thus, a gate may be partiaUy or fuUy generated at runtime, or a gate may be pre-generated before runtime 
with a binding process (e.g. for a URI or credential) performed at runtime, hi one embodiment, a gate generation 
tool such as the gate factory or the generation tool for pre-constnicted gates m^ be a Java-based tool to provide 
some level of platfonn independence. Alternatively, gate generation tools may be provided m any language, such as 
the native code for a particular device in the distributed computing environment 

Note that the distributed computing environment does not preclude a device from downloading part or all 
of a gate's code. . For example, m some embodimente, a service may provide gate code that may be downloaded by a 
client wishing to access that service. However, downloaded code may present size, security and/or safety risks. 

A more detailed iUustration of possible gate components for one embodhnent is shown in Figure 12. A 
gate may inchide its address (or name) 150, a destination gate address 152, a valid XML schema (or internal form 
thereof) 154, and a transport URI 153. hi other embodunents, a gate may also include an authentication credential 
156 Some gates may also mclude a lease 158 and/or a message conductor 160 to verify message ordering. 

A gate's name 150 may be a unique ID that vwll (for the hfe of the gate) refer only to it A gate may be 
addressed using its gate name 150. In one embodhnent, gate names may be generated as a combination of a string 
from an XML schema (e.g. from a service advertisement) and a random number, such as a 128-bit random number. 
The name 150 may allow clients and services to migrate about the networic and still work together, hi a prefeired 
embodiment, the gate address is mdependent of the physical message transport address and/or socket layer. Thus, a 
gate name may provide a virtual message endpomt address that may be bound and un-bound to a message transport 
address, to one embodhnent, a gate's name may be a Universal Unique Identifier (UUID) that may, for the life of 
the gate, refer only to it 

A gate name may persist as long as the gate persists so that different appHcations and clients executing 
Mdthm the same device may locate and use a particular gate repeatedly. For example, a gate may be created for a 
first client process executmg withm a device to access a service. After the first client process has completed its 
activity with the service, it may release the gate. Releasing the gate may involve un-binding the gate from the first 
client process's message transport address (e.g. IP and/or Port address). The gate may be stored m a gate cache or 
repository. A second client process executing widiin tiie same device that deskes to run the same service may locate 
the gate by its name and use it to access die service. To use the gate, the second cUent process may bind the gate to 
its message transport address, so that the message endpoint for the second chent process is a combmation of the gate 
name and the second chent process's transport address, hi another example, a client receive a dynamic IP 
address (e.g. a mobile chent). When the cUent's transport address changes, a gate name (or gate names) may be re- 
bound to the client's new transport address so that the client m^ still access a service(s) that it previously accessed 
without havmg to relocate the service and recreate the gate. A gate name may also be usefiil for process migration. 
A process and any associated gates may be checkpointed or saved at one node in tiie distributed computing 
environment and moved to another node. Tlie process may be restarted at the new node and the associated gates 
may be bound to the transport address for the new node so that the process wiH stiU have access to the external 
services to which it had access before bemg migrated. A gate may tmck the current location of another gate to 
which it is paired. Thus a service or chent may be migrated and still be accessible. For example, rephcated or load- 
balanced service hnplementations may be abstracted from clients of the service by tiie gate. 
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Thus, a gate name 150 provides a flexible mechanism by which to address a message endpoint m the 
distributed computing environment A gate name may be used to locate and/or address a gate over a wide range of 
networks, &om a local network to the Internet. Gate names may be independent of message transport so that a 
message endpoint (gate) may be moved from transport to transport by nnbindmg and rebmding to different 
5 underlymg transport addresses (e.g. IP/Port address pairs). 

In one embodiment, a gate may also be separated from a service so that the same gate may be used to send 
requests to different services over time. This may mvolve un-binding die gate's destmation gate address 152 and 
bmding a new destmation gate address to the gate. 

A gate may be unplemented as a layer above a device's transport layer (e.g. networking sockets). Each 
10 gate may include a transport reference 153. The gate name 150 may be bound to the transport reference 153 as 
described above. Multiple gates may share the same message transport For example, multiple gates may have 
transport references 153 to the same TCP/IP socket By sharmg the same message transport, the size and 
complexity of each gate may be reduced. A device m the distributed computing environment may have a large 
number of gates that need to send and receive messages. The message handling complexity for multiple gates may 
15 be reduced by sharmg a common message transport. The transport reference 153 may be a transport UKI (e.g. 
URL) or socket reference and may provide a mechanism for naming an underlying transport and sharing the 
transport with other gates. Multiple local gates may include a reference 153 to the same transport, however, each 
local gate may behave independently of the other local gates sending and receiving messages to and from its paired 
remote gate. 

20 The schema 154 may be downloaded from a space into the gate by the gate factory. The schema may be 

compiled mto an internal form suitable for quick access during a message verification process, hi one embodhnent, 
the schema may specify two groups of messages: cUent service messages and provider service messages. The client 
service messages group includes the description of all messages that the client may send (that the provider supports), 
and the provider service messages group includes the description of all messages that the provider may send (Aat 

25 the client receives). In one embodiment, either the client or provider may send a particular request to the space 
service to obtain a response message with either: the entire chent service messages, the entire provider service 
messages, the entire client and provider service messages, or a specific message of either the chent servdce me^^ 
or the provider service messages. In addition, once a gate has been constructed, a cHent may query as to the 
capabilities of the service without the gate actually sending a message, but instead by inspecting the gate's set of 

30 messages. 

As described above, a message gate may verify the sender of the message usmg an authentication 
credential, message content for type safety and according to an XML schema. However, it may also be deshable to 
verify that messages are sent between a client and a service m the correct order. It may be desirable to be able to 
provision appHcations (services) for clients to run without any pre-existmg specific frmctiondify related to the 
35 appHcation on the client (e.g. no GUI for the application on the client). For example, a Web browser may be used 
on a cHent as the GUI for a service instead of requiring an ^pUcation-specific GUI. Of the possible messages m the 
XML schema, the cUent may need to know what message next to send to tiie service. It may be desirable for the 
cUent to be able to determine which message to send next without requiring the cUent to have specific knowledge of 
the service. In one embodiment, the service may contmually send response messages mdicating the next input it 
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needs. The service would then accept only the corresponding messages from the client with the requested input 
specified. Other ad hoc scheme formessage ordering may also be employed. 

In another embodiment, a message conductor 160 may be employed in the gate or associated with the gate 
to verify the correct sequence of messages, as opposed to verifying each message's syntax (which may already be 
performed in the gate according to the schema). Message conductor 160 may provide a more general approadi for 
appUcation provisioning. Hie message conductor 160 may be specified in a service's advertisement The message 
conductor indication in a schema may allow code to be generated on or downloaded to the client during gate 
construction, which may provide the choreography needed to decide which message to send next to the service. A 

message conductor may be implemented as a Java application, a Java Script, WML script, or in other programming 

0 or scripting languages. 

In one embodnnent, the message conductor may accept as input an XML document (e.g. from a service 
advertisement) that presents the valid order or choreography for messages that may be sent between a cUent and the 
service. This XML document may also specify user interfece information and other rules. The conductor may parse 
this XML document into an internal form and enforce message ordering (and/or other rules) according to the 
5 enclosed ordering information. The conductor may prevent messages from being sent out of order. Or. if a message 
is sent out of order, an exception may be raised within the sending device. If amessage is received out of order, Ihe 
conductor may send an automatic response message back declaring the ordering error. The sender may then resend 
messages in the correct order. Note that in some embodiments, part or all of a conductor may be shared by several 
gates. Thus, a conductor may be linked to multiple gates. 
20 In one embodiment of a distributed computing environment, front ends for services (service interfaces) may 

be built in to clients. In one embodnnent, the service interfece may be a preconsfructed user interfece provided to 
the client by the service. In one embodiment, the service interface may be provided to the cUent in the service 
advertisement TTie service interface may interact on the client with the user of the service to obtam input for 
rmming die semce, and then may display results of nmning the service on the client A W may be a human, 
25 embedded system, another client or service, etc. In one embodiment, a cUent device may not be able to provision 
arbitrary services, as the client device may only be able to run services for which it has a front end buflt m. In one 
embodiment, a service mterface for a service may be implemented in a Web browser on the cUent 

In one embodiment, a message conductor and/or service interface may be external to the gate and thus 
abstracted from the gate and client The absfracted message conductor may provide provisioning of arbitrary 
30 services to any client device. In one embodiment, the message conductor may be written in code that may rm on 
substantialfy any platform. In one embodiment, the message conductor may be written in the Java language. In one 
embodiment, the message conductor may not require the arbifrary downloading of objects, for example, Java 
objects, returned to the client device. For example, very large objects may be retmned. and the message conductor 
may choose to not download these very large objects. In one embodiment, the message conductor may send XML 
35 messages to services from the cUent device on behalf of the cKent The message conductor may interact with the 
user of the service to receive input and display results. 

In one embodiment, a service mterface m^ be provided that interacts with the client (e.g. thru a user 
interface) to obtain all infohnation to run the service, and then may display either results of nmning the service or 
• information rxigarding the location ofresults, as appropriate. The service interface may be e^^ 
40 conductor 160 or may be in addition to and work with message conductor 160. The service interface may either be: 
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1. Built in to the client device and linis ran on the client. 

2. Downloaded to the client device from the space server. 

3. Run on the space server. 

4. Run on the service provider. 

In one embodiment, to a client, tbe distributed computing environment space server must support #1 always, 
indicate if #2 is supported (by advertisement in space), indicate if at least one of #3 and #4 is supported. Note that 
whether or not it supports #4 depends upon whettier or not the service provider supports #4. hi one embodiment, to 
a service provider, the distributed computing environment space server must support #4 always and indicate if it 
supports #3. 

Regardless of where the service interface runs, once a service is activated, the service interface interact 
with the cUent, displaying (remotely) requests for input on the client's display, and then displaying (remotely) results 
ofrunning the service. Such interaction with the client is implemented in terms of XML messages. 

The service interface and/or message conductor may meet the needs of a client user that may have 
discovered a service, but does not want to read a typically large, dry computer manual to figure out how to use the 
service. As the service interface and/or message conductor interacts with the user to request aU input that the service 
needs, Ihey may even provide short descriptions of the input requested if the user requests it Once the service 
interface has obtained the necessary information from the client, it may send XML messages to the service provider 
that runs the service. The ordering of the messages may be verified by the message conductor 160 m the gate. 

In a preferred embodunent, all messages flow flirough a gate. A gate may be configured to provide a flow 
control mechanism. For example, a service may need to handle a large amount of incoming and outgoing messages. 
Flow control may allow a senrice to keep up with high traflSc volume. Gates may be configm-ed to monitor 
messages for flow control tags. When a gate receives a message, it may examine that message for a flow control tag. 
The flow control tags may be XML tags. A message may include either an OFF tag or an ON tag, for example. If a 
received message includes an OFF tag, the receiving gate will stop sending messages to its paired destination gate. 
If the gate receives a message includmg an ON tag, it may resume sending messages. 

Thus, a service-side gate may monitor the use of its resources and trigger flow control if use of its resources 
exceeds a threshold. For example, a service may reduce its load by sending messages includmg QFF tags to one or 
more cUent gates. The cUent gates receiving the messages vwth OFF tags wfll stop sending messages to the service. 
Pendmg messages in the cfients may be buffered or may be handled by internal flow control mechanisms Oncethe 

service is able to handle more requests, it may send messages to one or more clients wifli ON tags so that the clients 
may resmne sending messages- In other embodunents, other flow control tags may be supported in addition to or 
instead of ON and OFF. Other flow control tags may mdicate to reduce message flow or that message flow may be 
increased. 

Message gates may be configured to perform resource monitoring. For example, since aU messages may 
flow through a gate, the gate may be configm«l to manage and/or track a cUent's use of a service (and possibly its 
associated resources such as memory or threads). A gate may be configured to track the activity of a software 
program, such as a cUent, by monitoring how much a resource, such as a service, is used or which and how many 
service resources are used. In one embodiment; a gate may generate or tnay facilitate generation of a cUent activity 
log. Each message and its destination or sender m^ be lo^ed. 
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A gate may also be configured to peifonn resource monitoring for flow control from the local (sending) 
side of a gate pair. If the client exceeds an allocated bandwidth of service (or resource) usage, the gate may 
automatically throttle back the flow of messages, for example. Thus, a client-side message gate may automatically 
trigger different flow control modes by monitormg the flow of outgoing messages. If the outgomg message flow 
exceeds a threshold, the gate may reduce or shut off its flow of outgomg messages. The threshold may be specified 
in a service's XML schema or advertisement In some embodiments, the threshold may be specified only for 
messages using certain service resources or for all messages. 

The gate may also be configured to determine when message flow may be increased or resumed. Iri one 
embodiment, the gate may maintam a count of outgoing messages that have been sent without the matching reply 
(response) received. When matching responses are received by the client-side gate, the count of outstandmg request 
messages may be decremented. When the coimts decrements below a specified outstanding request message 
threshold, the gate may increase or resimie sendmg new request messages. 

A gate may be configured to support message-based accounting and/or billing. A billing system may be 
implemented based upon the number and/or kind of messages sent and/or received by a message gate. Since all 
messages to and from a client may pass throiigh a gate, the gate may be configured to facilitate charging a client for 
service usage, for example on a per message basis or ^'pay as you go". Thus, a billing system may be implemented 
vrtthin the distributed computing enviromnent in which a user could be charged, for example, each time a message is 
sent and/or received by software running on behalf of the user. 

In one embodiment, a message gate may receive billing mformation from an XML schema, e,g. for a 
service. The hilling mformation may denote a billing policy and a charge-back URI. The charge-back URI may be 
used by the message gate to charge time or usage on behalf of a user. A message gate may make a charge-back by 
sending a charge message to the charge-back URI specified m the XML schema. Gates so configured may be 
refeired to as bill gates. The billing policy may indicate charge amounts per message or per cumulative message 
totals, etc. The billing policy may indicate how much and/or how often (e.g. after every x number of messages sent 
and/or received) to charge the user. The policy may indicate that only certain types of messages trigger charges, 
such a messages requesting a specified service resource. The billing policy may also indicate different billing 
models for different clients or classes of clients. For example, a billing policy may be configured (e.g. in a service's 
XML schema) so that some clients may pay a one-time charge when they create a gate to access the service. The 
policy may mdicate chents that are to pay as they go (e.g. per mess^e), or may indicate clients that are not to be 
charged at all. 

In some embodiments, a client may be too thin to support a fiiU gate, or a client may not include software to 
directly participate in the distributed computing environment In such embodiments, a server (such as ^e space 
server in which the service is advertised or another server) may be a frill or partial proxy gate for the client The 
server may instantiate a service agent (which may include a gate) for each service to be used by the client The 
service agent may verifi^ permission to send messages; send messages to the provider, possibly queuing them until 
the provider can accept the next one; send messages to the client, possibly queuing them until the client can accept 
the next one; and manage the storing of results in a result or activation space. See also the Bridging section herein. 

For example, as illustrated in Figure 13, a cUent may be a conventional browser 400 that does not support 
gates to participate directiy in the messagmg scheme described above. The brov/ser 400 may be aided by a proxy 
servlet (agent) 402. The browser user may use a search engine to find a Web page that fronts (displays tiie contents 
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of) a space advertising services within the distributed computiiig environment The user is able to point and click on 
the space Web page and, with the help of the servlet, to access services. The Web pages may include scripts, for 
example, Java or WML scripts, which may be used in connecting the browser to the proxy servlet Scripts may also 
be used to send messages to the proxy servlet. The servlet agent may translate Web page actions mto messages on 

5 behalf of the browser client. These actions may include navigating a space, starting services, and returning results. 
Result page URls (referencing pages contammg XML) may be returned directly (or translated into HTML or WAP 
ifneeded) to the browser, for display to the user. Thus, the browser-based client does not need to know how to start 
services, nor which messages to send during the service usage session. For example, a user of a WAP browser (e.g. 
on a cell phone) may connect to a space page, browse its contents (services), and then start a service, all by pointing 

10 and cUcking. The agent 402 provides the client mterfece between tiie conventional chent and the distributed 
computing environment 

The distributed computmg envhonment may mclude several different types of message gates for 
communicating between clients and services that support different features. For exan^le, as discussed above, some 
gates may support flow control or billmg. Another type of message gate may support a form of remote method 
15 invocation. Thistypeof gate may be referred to as a method gate. 

A gate is a secure message endpoint that sends and receives type-safe messages, e.g. XML messages. The 
remote method invocation (RMI) style gate may be referred to as a method gate. The direct data--centric gate may be 
referred to as a message gate. A method gate may be miplemented as a "layer" on top of a message gate. The exact 
implementation may be defined in the platform binding. 
20 Figure 14 illustrates the use of a method gate to provide a remote method invocation interface to a service. 

Method gates provide a method interface between clients and services. A method gate may be bi-directional, 
allowing remote method mvocations from client to service and from service to client. A method gate 172 may be 
generated from XML schema information 170 (e.g. from a service advertisement hi a space). The XML schema 
mfonnation 170 mcludes XML defining a method mterface(s). From this uiformation, code may be generated as 
25 part of the gate for interfacmg to one or more methods. Each method invocation (e.g. from a client application 176) 
m the generated code may cause a message to be sent to the service contammg the marshaled method parameters. 
The message syntax and parameters to be mcluded may be specified in the XML schema. Thus, the method gate 
172 provides an XML message mterface to remotely mvoke a service method. The method gate may be generated 
on the client or proxied on a server, such as the space server where the service method was advertised or a special 
30 gateway server. 

A service may have a corresponding metiiod gate that implements or is Imked to a set of object methods 
diat correspond to the set of method messages defined in the service's XML schema. There may be a one to one 
correspondence between the object methods unplemented by or linked to the service's method gate and the method 
messages defined by the service's XML schema. Once a service's corresponding method receives a message from a 
35 cUent to mvoke one of the service's methods, the service's method gate may umnaishal or unpack the parameters of 
die message invocation and then invoke the method indicated by the received message and pass the unmarshalled 
parameters. 

The method gate may provide a synchronous request-response message mterface m which clients remotely 
call methods causing services to return results. The underlymg message passing mechanics may be completely 
40 hidden from the chent. This form of remote mediod invocation may deal with method results as follows. Instead of 
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downloading result objects (and associated classes) into the client, only a result reference or references are returned 
in XML messages, in one embodiment. An object reference 178 may be a generated code pro^^ (e.g. results gate) 
representing the real object result 180 (still stored out on the net, for example). In other embodiments, the client 
may choose to receive the actual result object. In addition, once a client has received a result object reference, the 
client may use this reference to receive or manipulate the actual result object In one embodiment, the result 
reference includes one or more URIs to the real result 

The real result object(s) may be stored in a service results space (which may be created dynamically by a 
servlet, for example). This temporary results space may act as a query results cache. The results cache (space) may 
be patrolled by server software (garbage collector) that cleans up old result areas. Results returned from each 
method invocation may be advertised in the results space. A result itself may be or may include a method that could 
then be remotely instantiated by a client^ thus generating its own method gate. Therefore, the distributed computing 
environment may support recursive remote method invocation. 

As mentioned above, when a client uses a method gate to remotely invoke a service method, a reference to 
the method results may be returned from the service method gate instead of the actual results. From this reference, a 
results gate may be generated to access the actual result. Thus, the client or client method gate may receive a result 
URl and perhaps a result XML schema and/or authentication credential for constructing a gate to access the remote 
method results. 

In one embodiment, a service gate may create a "child gate" for the results. This child results gate may 
share the same authentication credential as its parent gate. In some embodunents, results may have a different set of 
access rights and thus may not share the same authentication credential as its parent. For example, a payroll service 
may allow a different set of users to mitiate than to read the payroU sendee's results (paychecks), 

A service method gate may retum a child results gate to the client gate as the result of the method. The 
cUent may then use the results gate to access the actual results. In one embodiment, the software program (client) 
receiving the results gate cannot distmguish between the results gate and the result itself in which case the resute 
gate may be an object proxy for the actual resrdt object. The results gate may also be a method gate that supports 
remote method invocation to result objects. In this manner, a chain of parent and child method/results gates may be 
created. 

In one embodiment, the method gates and remote methods may be in Java. In this embodiment, method 
results are correctly typed according to the Java typing system. When a Java method is remotely invoked as 
described above, the results gate may be cast mto the Java type that matches the result type. In this embodunent, 
method gates may be used in the distributed computing environment to allow remote Java objects to behave as local 
Java objects. The method invocation and results may appear the same to the client Java software program whether 
the real object is local or remote. 

See the Spaces section below for a fiirther discussion on the use of spaces for results. 

Message gates may also support publish and subscribe message passing for events. Message gates with 
event support may be referred to as event gates, A service's XML schema may indicate a set of one or more events 
that may be published by the service. An event gate may be constructed from the XML schema. The event gate 
may be configured to recognize some or all of the set of events published by a service, subscribe to those events, and 
distribute each event as the event is produced by the service. 
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The set of events for a service may be described in the service's XML message schema. For each event 
message in the XML schema, the event gate may subscribe itself as a consumer of that event hi one embodiment, 
an event gate subscribes to aU events indicated by the XML schema. Each event message may be named using an 
XML tag. The event gate may subscribe by sending a subscription message mcludmg the XML tag for the event to 
5 be subscribed to. 

When a corresponding event occurs with the service, the service may send an event message to subscribers 
indicating the occurrence of the event The event message may contam an XML event document and may be sent to 
each subscribed gate. When a subscribed gate receives the event message, the XML event document is removed 
from the message and the process of distribution begms. Event distribution is the process of handmg out the event 

10 document within the client platform. Each event consumer mthm the cKent platform may subscribe with the event 
gate for each type of event On Java platforms, the typing system is Java (converted from^t^^ 

The event consumer may supply an event handler callback method to tiie event gate. The event gate may 
store a Ust of these subscriptions. As each event message arrives at the gate (from the service producmg the event), 
the gate traverses the list of cUent consumers and calls each handler method, passing the XML event document as a 

15 parameter. In one embodiment, the XML event document is the only parameter passed to the handler caUback 
method. 

hi one embodhnent the event gate automaticaUy subsaibes itself for events on behalf of the local consumer 
cUents. As clients register interest with the gate, the gate registers interest with the event producer service. A client 
may also un-subscribe mterest, which causes the gate to un-register itself with the service producing the event 
20 An event gate may type check the event document using the XML schema just like a regular message gate 

does in the standard request-response message passing style described above. An event gate may also mclude an 
authentication credential m messages it sends and verif / die authentication credentials of received event messages. 

Note that any combination of the gate fimctionaHty described above may be supported m a single gate. 
Each type has been described separately only for clarity. For example, a gate may be a message gate, a mediod gate 
25 and ah event gate, and may support flow control and resource monitoring 

Service Discovery Mechanisms 

In one embodhnent, the distributed computmg envu-onment may mclude a service discovery mechanism 
that provides methods for cUents to find services and to negotiate the rights to use some or all of a service's 
30 capabilities. T^ote fiiat a space is an example of a service. The service discovery mechanism may be secure, and 
may track and match outgomg cHent requests with mcoming service responses. 

A service discovery mechanism may provide various capabilities mcluding, but not hmited to: 

• Finding a service using flexible search criteria. 

• Requesting an authorization mechanism, for example, an authentication credential, that may convey to the 
35 client the right to use the entire set or a subset of the enthe set of a service's capabilities. 

• Requesting a credential, doomien^ or other object that may convey to the cHentm^^ 

one embodhnent, the service's mterface may mclude interfaces to a requested set of die service's 
* capabilities. 
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• The tracking of discovery responses to tiie original requests. In one embodiment, each client request may 
mclude a collection of data that may also be returned in matching responses^ thus allowmg the requests and 
responses to be correlated. 

In one embodiment of the distributed computing environment, a service discovery mechanism may provide 
5 a flexible search criteria based upon an extensible grammar. In one embodiment, a service name, service type, and 
other elements, if any, being searched for may be matched with elements in an XML document In one embodiment, 
the :?GML document is the service advertisement for the service. XML may provide a flexible, extensible grammar 
for searchmg. XML also may provide type safety for matchmg elements. In one embodiment, the service names 
and service types may be type checked with the element types in the XML service advertisement 
10 In one embodiment, a distributed computing environment may mclude a mechanism for clients to negotiate 

service access rigjits. In one embodiment, the mechanism may be used to negotiate for a subset of a service's full 
capabilities. The result of the negotiation may be an authorization such as an authentication credential that conveys 
to the client the right to use the requested subset of the service's capabilities. 

In one embodhnent, the service discovery mechanism may allow a client to request a security capability 
15 credential from a service. In one embodiment, the client may present to the service a set of desired capabilities in 
the form of a protected (secure) advertisement The service may then respond with a capability credential that may 
convey to the client the rights to use the requested capabilities described in the protected advertisement. 

hi one embodiment, the distributed computmg environment may include a mechanism for a chent to 
negotiate service access rights and to then obtain a security credential or document that may be used to present the 
20 service's access interface to the set or subset of the service's capabilities that were requested by tiie client 

In one embodiment, a client that receives a capability credential from a service may generate a custom 
service access interface document that may be referred to as a ^'complete advertisement" In one embodiment, the 
complete advertisement may be an XML document The generated advertisement may provide access to the service 
c^^abihties as granted to the client by the received capability credential. In one embodhnent, an interface may be 
25 provided by the advertisement only to the service capabilities to which the client has been granted access by the 
capability credentiaL In one embodhnent, the client may be granted access to only required capabilities and to 
which the chent has access privileges. 

In one embodiment, the distributed computing en^oronment may provide a mechanism by which a client 
may negotiate capabilities with services. In one embodiment, the client may negotiate its c^abilities to the service. 
30 The service may then customize results based on the parameters negotiated with the cUent For example, a client 
that is capable of one bit display at a resolution of 160x200 may negotiate these parameters to the service, thus 
allowing the service to customize results for the client 

The following is included as an example of an XML capabilities message and is not intended to be limiting 
in any way: 

35 

<type name="Capabihties"> 

<element name="display" type="string**y> 
<element name="memory" type- 'string*'/> 
<element name="mune" type=^"string"^ 

40 
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</type> 

The distributed computing environment may include a mechanism that may allow clients to negotiate how a 
service is to return results of a service invocation. In one embodiment, during a capability credential request, a 
5 means by which to choose one of the results return methods may be conveyed to the service. The service may then 
generate a custom service advertisement that may convey to the client the results mechanism to be used, as well as 
the service interface. 

Thus, the service discovery protocol may allow clients to search for services (both space services and 
specific services or ^es of services). Service providers (or a listener agent) may respond to search requests by 

10 publishing or providing corresponding advertisements or URIs to corresponding advertisements. When a service 
provider responds to a discovery search request (either directly or through a listener agent), the provider may choose 
to publish a protected or an un-protected (complete) advertisement A protected advertisement may include the set 
of information necessary to obtain a complete advertisement Publishing a protected advertisement forces the client 
to obtain a valid credential from an authentication service before receiving the complete un-protected advertisement 

15 from the service provider. A complete un-protected advertisement is needed to create a gate, and therefore to use 
the service. Forcing clients to obtain a valid credential before receiving an advertisement may provide an additional 
level of security for the service provider. The security credential that must be obtained to receive the complete 
advertisement may be the same securily credential that is used to construct a gate to coirmiunicate with the service 
where the gate embeds the security credential in each message to the service. 

20 Whethor or not a service provider publishes a protected or complete advertisement may be based upon the 

service provider's desired level of security. Complete advertisements contain the service's message endpoint URI. 
Concealing this address may be a desirable security feature in many kinds of networks and deployment 
environments. However, sunple proximity networks hke IRDA, validate clients by requiring the client be m close 
proximity to the service provider. Concealing the IRDA message address from a close proximity client may just be 

25 redundant or too burdensome. In either case, the discovery search response choice may be left to the service 
provider. In a preferred embodiment, clients (or client gate factories) are configured to process either search 
response. 

Turning now to Fig. 41, a flow chart illustrating service discovery is illustrated accordmg to one 
embodunent A client locates one or more advertisements for service(s) the client may desire to use, as indicated at 
30 2072. In one embodiment, the client may locate services by sending a search message. Tummg now to Fig. 42, a 
flow chart illustratmg a more detailed example of locating service advertisements is illustrated for one embodiment 
The client may send (e.g. broadcast, multicast, etc.) a search message indicating service name and/or sendee type 
search criteria, as indicated at 2071, 

The following is an example for one embodiment of a search message that may be sent on one or more 
35 available message transports when a client wishes to search for services: 

<Discover> 

<Search> • 
<SearchType> Type<ySearchType> 
40 <SearcliNfame>Name<ySearchLName> 
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<SearchCommene>Coinment</SearchCominent> 

</Search> 
<Discover> 

5 nie search message is formatted according to a data representational langua^. The search and discovery 

tags may be required. The search tags may contain an optional set of search criteria, useful for narrowing the 
possible results returned from service providers, ine optional search criteria components may inctade a name (e.g. 
String). The name is compared with a service's name. If the search name matches the begmning or all of the 
service's name, a match may be declared for that service. In one embodiment, if the name isn't provided, aU service 

10 names are considered a match, 

Ihe optional search criteria components may also indude a 
. the service type, e.g, m the service description's "Title- field. If the search type matches the be^mmig or aU of the 

service*s type, a match may be declared. In one embodiment, if the type isn't provided, all service types are 

considered a match. For example, the type string may be "space" Avhen operating on a large network or ^service" 
15 when operating in a proximity network. Additional levels of type may be employed. 

Tlius, as indicated at 2072 in Fig. 42, the service name and/or service type search criteria maybe compared 

tonameandtypeinformationforserviceswithinthedistn^^ Each service provider that 

receives the search message may perform this comparison. Or a listener agent may perform the comparison for 

services registered with the listener agent 
20 The optional search criteria components may also include a comment (e.g. String). Tlie comment string 

may be returned in the body of the response message, and may be a nsefbl discovery message tracking tooL For 

example, a timestamp might be a usefiil comment string. 

\ search response may then be returned to the client indicating advertisements for services that match the 

search criteria. The foDowing is an example for one embodiment of a service provider response message that may 
25 be sent (e.g. unicast) by a service provider in response to the search message: 

<Discover> 

<SearchResponse> 

<SearchCornment> Comment String</SearchCommeirU> 

30 <Advertisement> Advertisement! </Advertisement> 

<Advertisement> Advertisement2 </Advertisement> 

<Advertisement> AdvertisementN ^Advertiserhen^ 

</SearchResponse> 
<yDiscover> 



35 



Tlie response message may include the set of advertisements that match the search criteria. In one 
embodhnent, if the search criteria weren't supplied, aU available advertisements are defined as a match. In one 
embodiment, if a comment string xvas supplied, the response also contams that same comment, possibly ^vidl an 
additional comment appended to tire end of the original string. 
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As mentioned above, a service may publish either a protected advertisement or a complete advertisement 
Thus the advertisements indicated in a response to a search may be protected or complete advertisements. A 
protected advertisement may not indicate the actual URI or schema that may be used to access the service. Instead, 
a protected advertisement may contain information on how to obtain a complete advertisement that includes the URI 
and schema to access some or all of a service's capabilities. In one embodiment, a protected advertisement may 
include the follovwng information: 

• Name and type of the service. 

• Capability descriptions of the service. 

UUID of the service. 

• URI ofauthentication service, \^duch will return a suitable cUent access (cs^^ 

• URI where the credential and UUID may be sent to generate a complete service advertisement 

A protected advertisement may be a smaller, surrogate XML document fragment (a meta-advertisement). 
A protected advertisement may provide a level of indirection between the client and the real advertisement, 
requiring the chent to negotiate for access to the real advertisement Publishing a protected advertisement instead of 
a complete advertisement forces the client to obtain a valid credential from an authentication service before 
receiving the complete un-protected advertisement from the service provider- 
Returning to Fig. 41, after the client receives a response to it s search, it may select one of the 
advertisements for one of the services for which it wishes to negotiate access by requesting a capability credential, 
as indicated at 2074. This advertisement negotiation process may provide additional security in the distributed 
computing enviromnent (e.g, by hiding real advertisements), while at the same time adding some flexibility. For 
example, during the advertisement negotiation process, a client may request a custom set of messages for accessing 
the service. The client may provide die desned name and type of mterface. One example of requesting a custom set 
of messages may be requestiing only ^'read" access as opposed to "read" and "write" access to a service. When 
requesting a custom message set, the client may wish to only use a subset of the service's fiill capabilities 
(messages). The right to use die requested set of messages may be verified during the negotiation. If the client 
doesn't have die proper access rights to the requested capabilities, the negotiation fails, otherwise a valid credential 
is returned to the client 

A client may also request additional access message sets. Client may provide the desired name and type of 
interfece. Some clients may require the use of more than just the base access messages. A client may request a set 
of additional access messages. Some of these access messages may even address platform specific issues such as 
performance and memory footprint size. 

A client may also request that a non-XML content type be used to represent data passed in die messages 
between client and service. Some clients may not support XML, but still wish to access services within the 
distributed computing environment To allow non-XML clients access to services, non-XML content may be 
tunneled within an XML message. The non-XML content may be wrapped by an XML tag on the sending side, and 
then extracted on the receiving side. 

Service providers may benefit from the use of protected advertisements in several ways. As abreatfy 
mentioned, protected advertisements prevent unautiiorized clients from receivmg complete advertisements, and 
* allow capability negotiation. Protected advertisements may also allow for dynamic advertisement generation. When 
a client negotiates for a complete advertisement, an opportunity to generate a custom one "on the fly^ exists. This 
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feature allows smaller XML document fragments to be downloaded to clients since the complete advertisement need 
be only as big as requested. This feature also allows a service to effectively pubUsh advertisements specific to client 
requirements. 

Protected advertisements may also fecilitate service queries. Protected adverdsements may be published 

instead of complete advertisements to feciUtate dynamic searches for services that match the cHent requested set of 

capabilities. Protected advertisements may indicate a seivice's capabUities in a searchable format without mcludmg 

a complete message schema for those facilities. 

In one embodiment, a protected advertisement may include the followmg ™L docmnent elements: 

• Kame(Hmnan readable, non-canonical string) 

• Canonical name of service (e.g- UUID) 

• B^eMetiiod Interface Description (Message hit^fe^e Description) 

, -Title (Message interfece standard name that conveys a type) 

- Provider Name (Standards Body Name) 

- Version (Version of standard (type) implemented) 

- Info URI (Standard body's web page) 

• Additional Access Method Interfece E>escnptions 

- List of descriptions containing: Title, Provider, Version, Info URL 

• Content Type Descriptions 

-List of descriptions containing: Title, Provider, Version, Info URI. 

• Credential 

- Service's credential to enable chent to authenticate service 

• Authentication URI 

- A message inay be sent here to obtam a suitable credential that grants access to this service, 

• Generate Real Advertisement URI 

- A message may be sent here to generate a complete advertisement, given a protected advertisement 
that contains the client's requested capabilities. 

To obtain a complete advertisement, given a protected advertisement, a client (e.g. client's gate fectoiy) 
obtains a capabihty credential from the specified authentication service by sending a credential request message, as 
indicated at 2074 in Fig. 41 . The credential request message may be sent to an authenticated service URI specified 
m tiie advertisement for the service the client desires to access, men the client's request is received, a capability 
credential is generated, as indicated at 2075. The capabihty credential may be generated according to capabUities 
requested by the client and/or the client's level of authorization. Hie cUent then receives the capabi% credential m 
response to its request, as indicated at 2076. The i^onse may contain the credential needed to generate the 
complete advertisement This credential may be the same credential that the cUent's gate mcludes in each message 
sent to the service. 

If the advertisement was a protected advertisement, fte client then may send an advertisonent request 
message containmg the capability credential and an identification (e.g. UUID) of the service to the second URI 
. specified in the protected advertisement, as mdicated at 2078. The.client tiien receives a complete advertisement, as 
indicated at 2080. The response to this second message is the complete advertisement of the specified seance. If 
the advertisement mdicated m the credential request was aheady a complete advertisement, 2078 and 2080 may be 
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;kipped. Figure 43 compares the difference in the discover process when the published advertisement is a complete 
advertisement versus a protected advertisement Returning to Fig. 42, a complete advertisement and the capabUity 
credential may then be used to create a gate, as indicated at 2082. 

An example of a credential request message accordmg to one embodiment is as follows: 

5 ■ " , ■ . 

<Discover> 
<CredentialRequest> 

<UUID> uuid<AJUID> 

<AdvertisementURI>adv uri</AdvertisementlJRI> 
10 <ProtectedAdvertisement>adv</ProtectedAdvertisemenP> 
</CredentialRequest> 
<yDiscova:> 

The credential request message may include an identification (e.g. TJUID) of service to which access is 
15 desired. The credential request message may also include an advertisement URI refer^cing the advertisement or 
the advertisement (by value). The Advertisement may be passed by vahie or by refenaice during this negotiation 
process. Advertisements may be complete or protected. If the advertisement passed in the credential request 
message is already a complete advertisement (e.g. sendee relumed it m the semt:h response), then the credential 
returned from the service will allow access to all of the service's capabilities (aU access methods + aU messages). 
20 A protected advertisement may be edited to contain just the desked set of access method and content 

descriptions. The edited protected advertisement may be passed in the credential request message. Thus, a client 
may build and expresses its set of requested capabiUties by editing the advertisement, or copying the relevant 
infonnation from the origuaal to a new instance. 

An example of a credential request response mess^e according to one embodmient is as foUows: 

25 

<Discover> 

<Credentia3RequestResponse> 

<Credential>c^ability credential</Credential> 
</CredentialRequestResponse> 
30 </Discover> 

If the client has proper authorization, the credential request response message includes a capability 
credential givmg the client requested access to the specified service (e.g. identified by UUID), including the set of 
capabilities dejSned in the protected advertisement This credential may then be stored m the cHent's gate and then 
35 added to each message sent to tile service. The service tiien uses tiiis credential to verify the client's right to use a 
service's capabilities. 

The capabQity credential structure and contents may be defined by die service. In one embodiment, die 
credential at least includes a reference to die protected adveitisenient used during tiie negotiation, and a security key 
to validate the' client's identity. If tiie advertisement passed m the credential request message is akeady a complete 
40 advertisement (e.g. service returned it in the search response), tiien tiae credential retumed from the service will 
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allow access to all of the service's capabilities. If the service provider doesn't support or require credentials at aH, 
the response message may contain an empty credential (null). 

In some embodiments, a capability credential may be used to support the notion of sessions. A service 
provider may embed a session ID within the credential, and be sure that the client gate wiU pass it (credential 
5 containing ID) to the service provider in each message. The entire credential may be defined by the service provider 

and hence may contain any number of fields, including a sessionID, or other demuxing IDs, etc. 

An example of an advertisement request message according to one embodunent is as follows: 

<Discover> 
10 <AdvertisementRequest> 

<Credential> czqjability credential</Credential> 

</AdvertisemenfRequest> 

</Discover> . 

15 The advertisement request message mcludes the credential from the credential request response message. 

In one embodiment, this credential mcludes enou^ information to identify the origmal protected advertisement 

An exan^le of an advertisement request response message accordmg to one embodiment is as foUows: 

20 <Discover> 

<AdvertisementRequestResponse> 

<Advertisement> CompleteAdvertisementl </Advertisement> 
</AdvertisementRequestResponse> 
<^'Discover> 

25 

The advertisement lequest response message mcludes the complete advertisement referenced by the 
(edited) protected advertisement Note that the credential found in Ae complete advertisement may be the gate 
credential to be passed in every message. 

Spaces are implemented by services of type space. Discovering a space may be accomplished either by 
30 specifying the "space« type in the search criteria, or by parsmg the set of search results, and then extracting all 
"space'* advertisements. Spaces may be populated with advertisements (protected or unprotected) using the above 
described discovery protocol. The population may be initiated by the space service itsel£ or by another network 
service agent 

Once a space is discovered, its contents m^ be examined nsmg standard space service navigation 
35 messages or as defined in the space service advertisement For each advertisement witiiin the space, a client gate 
factory may build a gate (using the credential and advertisement request messages) to access the named service. 

In one embodiment, aU advertisements (protected and complete) contam a service credential. Clients may 
validate this credential before requesting a cUent capability credential This procedure may prevent un-authorized 
services from publishmg advertisements using the discovery protocol. . 
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For one discovery protocol implementation example, the protocol may be on the wire data fonnat, wMch 
may be implemented in many different ways depending on the transport beneath it The discovery protocol 
implementation may be defined in a platform bindmg. For example, a possible IP bnplementation may be one in 
which space services listen for UDP multicasts of space search messages. A client/service may multicast a space 
5 search message and waits for a response. Space services may unicast a space search response message containing an 
advertisement 

In one embodiment, the distributed computing enviroimient may include a mechanism for tracking sem^^ 
discover search requests and responses to the requests. In one embodiment, search request and response messages 
may include a field that may be used to include a string or an XML document In one embodiment, the string or 
10 XML docmnent mcluded in the field of a request message is also returned in the response message. In one 
embodiment, the string or XML docmnent is i«iuired to be returned in the response message. In one embodiment, 
the string or XML docmnent may include additional information inserted in or appended to the string or document 
when returned in the response message. In one embodiment, this mechanism may be used in debugging complex 
. systems, to one embodiment, this mechanism may also provide to clients a method for choosing services to access 
15 by using the string or XML docmnent to pass custom search information between a cUent and service that may only 

be understood by the client and service. 

For an example of fields in i^uest and r«!ponse messages, refer to the SearchComment fi^^^^ 

and search response messages described above. 

For some devices that provide a service, the overhead of finding a space to advertise its service and 

20 maintain that advertisement is undesirable. In one embodiment nrther than searchmg for and maintaining a space or 
spaces to pubUsh service advertisements, services on some devices may transmit their advertisements in response to 
comiection requests. For example, a printer device with a printer service that is available on a proximity basis may 
not maintain an advertisement m a space (on the device or external to the device). Instead, when another device 
establishes a comiection with the printer device (for example, a user with a laptop rmming a cBent desires to print a 

25 document), the printer service may transmit die service advertisement to provide the XML service schema for 
connecting to and nmning the service that provides printing fimctionaUty on the printer device. Also, some devices 
may only maintain advertisements for tiieir services in a certain vicmity or local network. Such a device may not 

desire to support or may not have access to b^sports for broader accessibiUty. 

One example of a service device in wMch it may be desirable for the device to avoid or Ihnit maintain^ 

30 service advertisements in a space is a device whose fimctionality is avaDable on a proximity basis. Proximity-based 
services may provide advertisements of their fimctionalily upon request Hese advertisements may not be broadly 
accessible. For example, proximity-based services may be provided in a wireless communications system. Hie term 
"wireless" may refer to a communications, monitoring, or control system in which electromagnetic or acoustic 
waves carry a signal through atmospheric space rather than along a wire. In most wireless systems, radio firequency 

35 (RF) or infrared (IR) waves ar« used. Typically, in proximity-*ased wireless systems, a device comprising a 
transceiver must be witiiin range (proximity) of another device to establish and maintain a communications channel. 
A device may be a hub to connect other devices to a wireless Local Area Network (LAN). 

As mentioned, embodiments of the distributed computing environment may provide a mechanism using one 
or more spaces tiiat allow clients to rendezvous with services. In a proxunity computing envkomnent, one 
40 embodiment of the distributed computing enviromnent may provide a service discovery mechanism that clients may 

37 



WOOl/86394 PCT/USOl/15134 

use to discover services without using spaces as rendezvous points. An exan5)le of a proximi^ computing 
environment is an IrDA point-to-point communications environment In a proximiQ' computing environment, the 
proximity mechanism may find the "physical" location of the service for the cUent For example, in an IrDA 
environment, the client device may be physically pointed at the device including the service(s) that the cUent desires 
5 to use. 

In some situations a cUent may have physically discovered the device fliat contains services the client 
desires to run. For example, a person with a PDA client may be in close proximity to a printer participating within 
the distributed computing environment Various scenarios may emerge with close proximity devices. When clients 
are in close proximity to devices (e.g. publishing services), much of the discovery process may be s In 
10 these cases, the user may select the device. For example, IRDA devices are pointed at each other to establish a 
discovo: connectioii. 

Close piDximity devices for whidi security isn't an issue (like an IRDA printer) may publish complete 
advertisements. Instead of encapsulating services m spaces, close proximity devices may directly respond to the 

discovery protocol. 

15 Close proximity devices for which security is an issue (e.g. an ATM) respond to discover requests 

widi protected space advertisements. The space may cont^ aH the services si^ort^ ^ ^ device. Once access 
to the space has been granted, cUents m^ browse complete advertisements stored in fte space. Iliis model 
presumes that all services stored in the space can leverage the space secmity model, and not provide a separate 
model. Altematively, close proximity devices for which security is an issue may respond to discover requests with 
20 protected advertisements for each service. Each service may provide its own authentication service. Combinations 
of.each proximity device scenario are also contemplated. 

The proximity service discovery mechanism may enable the cUent to directly look for service 
advertisements rather than sending a search request to a space to look for service advertisements. Since the client 
device may have established a proximity comiection to the service device, the client may directly request the desired 
25 service. For example, a PDA client device may establish a proximity connection to a printer device; the client may 
"know" to request a printer service coimection on the printer device. 

In one embodiment, the client may send a proximity service discovery message to the service device. The 
message may mclude information that may specify a desired service on the service device to which the client device 
has a proximity connection. In one embodiment, a service on the service device may respond to the proximity 
30 service discovery message, and may send to the client tiie service advertisement that the cUent may use to connect to 
the desired service. The proximity service discovery message may also include mformation that may be used to 
authenticate the client and to establish the client's capabilities on the service. Using the received sendee 
advertisement, the cUent may establish a gate to establish communication vrith the desired service. 

An example of a system m v\iiich a chent device directly discovers a service on a service device over a 
35 proximity link is illustrated in Fig. 44. A client device 2150 includes a proximity port (e.g. an LrDA port) 2156 
configured to fonn a direct pomt-to-pomt communication link, or proximity link. Client device 2150 may include a 
cHent 2152 that may desire to use a service over the proximity link. The client 2150 may be an appHcation or a 
/ . combination of circuitry and software. A chent interface 2154 may be configured to direcdy request over the 
proximity link a document that describes an interfece to access a desired service. The mterface 2154 may also be 
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configured to receive such a document directly over the point-to-point communication link and use the information 
from the document to access the service, such as by constructing a gate. 

A service device 2170 may include a proximity port 2172 and may fonn a proximity link with client device 
2150. The service device 2170 may include code and/or hardware to implement one or more services 2176. 
5 Service, device 2178 may also be configured to provide one or more documents 2178, or advertisements, over the 
proximity link. An advertisement 2178 may describe a message schema for accessing a service 2176 provided by 
service device 2170. A service interface 2174 may be configured to receive over the proximity link a request fi-om a 
client for a document 2178 that describes an interface to access a service 2176. The interface 2174 may also be 
configured to provide document dhectly to a cUent over fee proxunity link and provide a message endpomt (e.g. 
10 gate) for communicating with a client The service interfece may also provide a mechanism to authenticate clients' 
requests to access the service. 

Figure 45 illustrates a basic flow diagram illustrating client discovery of a proxnnity service, A client may 
form a proximit/ connection to a service device, as indicated at 2190. For example, a client device may be a 
personal digital assistant (PDA) with an address book client The client my need to print a portion of the address 
15 book. The PDA may include an IrDA port and may be m proxunity of a prmter with an IrDA port The client may 
estabhsh a proxunity connection to the printer. The cUent may feen, as indicated at 2192, request a service 
advertisement over the proximity connection, such as a printer service advertisement Then cUent may then receive 
Ml advertisement matchmg its request, as indicated at 2194. The advertisement may be received dhectiy fix)m tiie 
service device over the proximity connection. The client may tiien construct a gate according to the advertisement 
20 to access the service, as indicated at 2 196. 

Thus, proximity devices may avoid the overiiead of usmg spaces as a rendezvous point for chents 
discovering services. Nevertheless, it may still be desirable to publish advertisements for services (e.g. proximity- 
based services) that do not desire to or cannot maintain theh advertisements m a space tiiat is broadly accessible. In 
one embodunent of a distributed computing environment, a device that establishes a connection witii a device that 
25 does not publish its service advertisement(s), such as a proxitoity-based device, may publish service advertisements 
received from the non-publishing device. For example, a device that establishes a connection with a proximity- 
based device and that has an alternate transport connection(s) m^ publish (or repubUsh) service advertisements 
received from the proximity-based device in die alternate transport environment thus allowing the proximity-based 
device service(s) to be used by otiier devices (through the (re)pubHshed service advertisements) which are outside 
30 the normal proximity range of the device. 

The publishing device may locate a locally published service advertisement for the proximity-based device 
through a discovery and/or lookup service, or alternatively the service adveitisement may not be published by the 
local service device, but instead may be sent to the publishing device by the local device vtpon the establishment of a 
proxnnity connection, as described above. In one embodunent, the repubhshed service advertisement may be made 
35 available as long as the device maintaming the advertisement is connected to or able to connect to the local device. 
For example, if the pubUshmg device is disconnected from the local device (for example, moves out of proxnnity 
range of the device), the service advertisement may be made stale or removed. A lease mechanism nmy be provided 
to aUow the space contaming the adverti?ement to send lease renewal messages to the publishmg device. The 
pubHshmg device may verify its connection to the local device, thus allowing tile space to detect ^en the local 
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device is no longer available. Rules for how tiie service advertisements are republished may be provided by the 
local device or by an administrative policy for the local vicmity (e.g. proximity area) or local network- 
Figure 24 illustrates an example of a device bridging proximity-based devices onto anotiier transport 
mechanism to allow the services provided by the proximity-based devices to be accessed by devices outside the 
proximity range of the devices, according to one embodunent A publishing device 1404 may be connected to a 
network 1412, such as an Ethernet LAN or the Intemet, etc., and may establish and maintain proximity connections 
1414 with proxhnity devices 1400 and 1404. Proximity connections may be wureless connections or vwred LAN 
connections, for example. ^ Proxhniiy devices 1400 and 1402 may each send a service advertisement to the 
pubUshing device 1404 upon connection, or, altematively, the publishing device may locate the service 
advertisements using a discovery and/or lookup service for the proximity connections. The pubhshmg device 1404 
may then make the services provided by the proximity devices available to other devices 1408 and 1410 on die 
network 1412 by repuhlishmg the service advertisements 1416 and 1418 in space 1406, Space 1406 may be stored 
on the publishing device or on other devices connected to the LAN (including devices 1408 and 1410). 

Other devices on the LAN includmg devices 1408 and 1410 may then discover space 1406 and look up the 
republished service advertisements 1416 and 1418 for the proximity-based devices, establish gates to communicate 
to those services (device 1404 may act as a proxy ot bridge) on the proximity-based devices 1400 and 1402 using 
tibe XML message passing methods described previously, and send requests and receive results to the proxinrily 
devices. Publishing device 1404 may act as a bridge between the networic 1412 and the projdmity connections 1414 
to the proximity-based devices. 

Matching Component f Service! Interfaces 

The distributed computmg environment may provide a mechanism for matching a component (for example, 
a service) specification interface with a requested interface. For example, a client (which may be a service) may 
desire a service that meets a set of interface requirements. Each component may have a description of the interface 
to which it conforms. The specification interface matching mechanism may allow a component that best matches a 
requestor's interface requirements to be located. The specification interface matching mechanism may also allow 
for "fiizzy" matching of interface reqmrements. In other words, the mechanism may allow matching without 
requiring the exact specification of all aspects of the interface, tiius providmg a nearest match (fuzzy) mechanism, 
hi one embodiment, the specification mterface matchmg mechanism may be implemented as a multi-level, sub- 
classing model rather than reqmring specification at a single interface level 

In one embodiment, a component may use an XML Schema Definition Language (XSDL) to describe its 
interface. XSDL may provide a human-interpietable language for describmg the mterface, simplifying activities 
requiring human intervention such as debuggmg. In one embodiment, the mterface desaiption may be provided as 
part of an advertisement (for example, a service advertisement) as described elsewhere in this document 

Using the specification interface matching mechanism, a basic desired interface may be compared to a set 
of component' interface descriptions. One or more components matching the basic desired interface may be 
identified. The interface descriptions may mclude subclass descriptions describing more specifically the mterfaces 
provided by the components. Li the search process, &e class type hierarchy may be exammed to determine if a 
given class is a subclass of the search type. In one embodiment, subclasses may inherit properties of the base class, 
and thus the subclass-specific mformation may not be examined in this phase. Thus, the search may be perfonned 
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genericaUy. The identijaed components may be searched at the next (subclass) level. The search may become 
spedfic to the subclass and may be perfomed by interpreting the subclass Mormati^^ 

description. The search may continue through one or more subclasses until one or more components is detenmned 
which may provide the nearest match to the requestor's desired mterface. 

In one embodiment, an interface matching mechanism may provide the ability to distinguish among two or 
more components that implement similar interfeces. In one embodiment, the interface matching mechanism may 
provide the ability to distinguish among different revisions of the same compon 

In one embodiment, a component description may be provided that includes a specification of interface 
to which the component conforms. The component description may also include information about the component 
itself. TTie interface description and/or ftic component information may be used to differentiate among different 
implementations of a given interfece. The com5)onent descriptions may mclude a canonical identifier and version 
information. The version information may aUow component revisions to be distinguished. In one embodiment, tbe 
component description may be provided as part of an advertisement (for example, a service advertisement) as 
described elsewhere in this document 
15 In one embodiment, components may be searched for a particular canonical identifier. Two or more 

components may be identified with matching canonical identifiers. One or more components may be selected from 
among &e components with matching canonical identifiers, Tbe selection procedure may use an interfece 
specification version, a component implementation specification, a component implementation specification version, 
other information or a combination of information from the component description to produce a set of one or more 
20 components that best match die requestor's requirements. 

Spaces 

As mentioned above, the distributed computing environment relies on spaces to provide a rendezvous 
mechanism that brokers services or content to cHcnts. Figure 15 iUustrates tiie basic use of a space 1 14. Service 
25 providers may advertise services in a space 114. Clients 110 may find the advertisements m a space 114 and use the 
information fi-om an advertisement to access a service usmg the XML messagmg mechanism of the distributed 
computing environment Many spaces may exist, each containing XML advertisements that describe services or 
content Thus, a space may be a repository of XML advertisements of services and/or XML data, which may be raw 
data or advertisements for data, such as results. 
30 A space itself is a service. Like any service, aspace has an advertisement, which a cHent of die space must 

first obtain in order to be able to run that space service. A space's own advertisement may include an XML schema, 
a credential or credentials, and a URI which indicate how to access the space. A cfient may construct a gate firom a 
space service's advertisement in order to access tiie space. A cUent of a space may itself be a service provider 
seekingto advertise in tiiat space or modify an existing advertisement Or a client of a space may be an application 
35 seeking to access a service or content listed by the space. Thus, spaces may provide catalysts for the interaction 
between clients and services in the distributed computing enwonment 

A space may be a collection of named advertisements. In one embodiment, naming an advertisement is the 
process of associating a name string with an advertisement The association m^ t^e place upon storing an 
advertisement in a space. Removing an advertisement from a space disassociates the name from the advertisement 
40 A space may be created with a smgle root advertisement that describes die space itself Additional advertisements 
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may be added to a space. An advertisement's name may locate Hie advertisement within the space, including 
specifying any necessary graphing information such as a hierarchy of names. In a preferred embodiment, the- 
distributed computing environment does not dictate the structure of a space. That is, spaces may be structured as, 
for example, a flat un-related set of advertisements or a graph of related advertisements (e.g. commercial database). 
5 Smce, in a preferred embodiment, the distributed computing environment does not dictate how a space actually 
stores its content, spaces may be supported by small to large devices. For example, a simple space may be tailored 
to fit on small devices, such as PDAs, More advanced spaces may be implemented on large severs employing large 
commercial databases. 

As mentioned above, a space may contain advertisements for services in the distributed computing 
10 environment An advertisement may provide a mechanism for addressing and accessing services and/or content 
within the distributed computing environmait An advertisement may specify a URI a service. In some 
embodiments, tide UM may allow for the service to be accessible over the An advertisement may also 

include an XML schema for the service. The XML schema may specify a set of messages that cUents of the service 
may send to the service to invoke fimctionahty of the service. The XML schema may define the client-service 
15 interface. Together, the URI and the XML specified in an advertisement may mdicate how to address and access the 
service. Both the UKI and schema may be provided in XML as an advertisement in a space. Thus, a mechanism for 
addressmg and accessing a service in a distributed computing environment may be published as an advertisement m 
a space. CUents may discover a space and then lookup individual advertisement for services or content 

Figure 16 illustrates advertisement structure according to one embodiment An advertisement 500, like 
20 other XML documents, may include a series of hierarchically arranged elements 502. Each element 502 may 
include its data or additional elements. An element may also have attributes 504. Attributes may be name-value 
strmg pairs. Attributes may store meta-data, which may facilitate describing the data within the element 

In some embodiments, an advertisement may exist m dififerent distinct states. One such state may be a 
drafted state. In one embodiment, advertisements may initially be constructed in a drafted state that exists outside 
25 the bounds of a space. The creator of an advertisement may construct it m a variety of ways, includmg using an 
XML editor. Access to elements and attributes m the drafted state may be at tiie raw data and meta-data levels using 
any suitable means. TypicaUy, events are not produced for changes made to advertisements in the drafted state. 
Therefore, the creator of the advertisement may be free to add, change, or delete elements as weU as to achieve the 
desired attribute set, and then publish the advertisement for the rest of the distributed computing environment to see, 
30 In one embodunent, another possible state for advertisements is a published state. Advertisements m^ 

move to the published state when inserted mto a space. Once the advertisement is in a space, interested cUents, and 
services may locate it, e.g. usmg its name and/or its elements as search criteria. For example, search criteria may be 
specified as an XML template document that may be compared (e.g. by tiie space service) with the advertisements in 
flie space. Published advertisements may represent "on-line" services ready for clients to use. The message address 
35 (URI) of the service may be stored as an element m the advertisement Advertisements liwt are removed from the 
space may transition back to the drafted state where tiiey may be discarded or held. Removal may generate an event 
so interested listeners may be made aware of the change. Message gates are typically created from published 
advertisements. 

In one embodunent, yet anotiier possible state for advertisements is a persistent archived st^^ 
40 procedure may turn a live published advertisement into a stream of bytes tiiat may be persistently stored for later 
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reconstruction. Archived advertisements may be sent (e.g. in their raw XML form) from die space to an archival 
service. The UIU for an advertisement's archival service may be stored as an element in the advertisement XML 
may provide a format for storing and retrieving advertisements and representing the state of advertisement elements 
sufficient to reconstruct the advertisement object(s). Advertisements may be stored in other formats as weU, 

5 depending on archival service nnplementation. The process of makmg a published advertisement persistent may 
prepare the advertisement for the persistent archived state. Persistent advertisements may be stored (e.g. by an 
arcyval service) for fiiture use in a persistent storage location such as a file or a database. A space through the 
archival procedure may enable advertisements to be stored, however tiie space does not necessarily play a role in 
how persisted advertisement entries are actually stored. How persisted advertisements are stored may be determined 

10 by the advertisemenf s archival service. Typically, no events are generated on behalf of archived advertisements. 
Also, changes may not be aUowed for advertisements in the persistent archived sta^ 

Advertisements may be archived and removed or just archived If an advertisement is archived wi&out 
removing it from the space, the space will store a shadow version of the advertisement Access to an archived 
service may cause the advertisement to 'tault-m" from its persistent backing store on demand This feature may 

15 allow advertisements to be fiUed, from LDAP (Lightweight Directory Access Protocol) entries for example, on 
demand 

Figure 17 illustrates one example of advertisement state transitions that an advertisement may undago 
during its lifetime. First, an advertisement may be constructed, as indicated at 1. During construction, the 
advertisement is in the drafted state. Then, the advertisement may be inserted in a space, as indicted at 2. The 

20 advertisement may be inserted as a pubUshed parent. The advertisement is in the published state after being mserted 
in a space. An event (e.g. AdvInsertEvent) may be generated when the advertisement is inserted in the space. 
Events are more fiiUy discussed below. The advertisement may be archived and made persistent, as indicated at 3, 
which may transition the advertisement to the persistent archived state. An advertisement may also be published 
from the persistent archive state, as indicated at 4. An advertisement may be removed from a space and transition 

25 back to the di^ed state, as indicated at 5. An event (e.g. AdvRemoveEvent) may be generated ^en the 
advertisement is removed 

In one embodiment, the archived, persistent state is not used In this embodiment, state changes 3 and 4 
also are not used In this embodunent, an advertisement is eitiier in the drafted state or in the publ^^^ 
Advertisements stored in a space may have the foUowing standardized elements and/or ato^ 
30 (may be an element), creation date (may be an attribute), modification date (may be an attri^^^^ 
service URI (nmy be an element), and/or persistence archival servi^ 

A space itself is typically a service. A space service may provide the ability to search for advertisements in 
the space, which may include searchmg the space by type of advertisements. A space service may also provide 
facilities to read advertisements, write (publish) advertisements, and take (remove) advertisements. A space may 
35 also provide tiie ability to subscribe for space event notification messages. Some spaces may provide extended 
facilities, such as fecilities to navigate space relationship graph by position; read, write or take advertisemait 
elements; read, write or take advertisement attributes; and subscribe for advertisement event notification messages. 
Space facilities are described in more detail below. A space's c^abilities are embodied in a space advertisement's 
message schema. From tiie message schema, space address, and authentication credential, a client message gate may 
40 be created to access the space and its facilities. 
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Spaces and aO advertisements within a space may be addressed using URIs, In one embodiment, space and 
advertisement names may follow UKL naming conventions. The use of URIs, e.g. URLs, for addressing spaces may 
allow spaces to be addressable throughout the Internet, in some embodiments. 

The space message recipient (a space service) may be specified using a URI which may have been received 

5 m a service advertisement for the space. The URI may include a protocol, host, port number, and name. The 
protocol may name the protocol that may be used to move messages between clients and the space (reliable or 
un-reliable sockets, for example). Thehostandportnumbermay be protocol dependent IDs. The name may be the 
space name followed by advertisement, element and/or attribute name. In one embodiment, a pathname may be 
used to identify an advertisement in a space. Pathnames may be either absolute or relative. Absolute pathnames 

10 name the space as well as an advertisement Relative pathnames are relative a designated advertisement within an 
assumed space. In one embodiment, the syntax rules governing the construction of paSfanames is that of the URI 
(Uniform Resource Identifier). M that embodiment, advertisement and space names therefore m^ not contam any 
URI reserved characters or sequences of characters. Pathnames to elements and attributes may also be specified 
usmg a URI. In general, element and attribute names may be upended to the pathname of an advertisement, such 

15 as: 

http:/y5ava.sun.com/spacename/advertisement/element/attribute. • 
In one embodiment, the distributed computing cavironment may include a mechanism that allows a chent 
to discover the URI of a space but restricts access to the service advertisement for the space. In one embodhnent, 
rather than returning the full advertisement to the space, the URI of the space and the URI of an authentication 
20 service for the space may be returned. In order for tiie client to access the documents or services advertised in the 
space, the client first may authenticate itself to the authentication service at the URI provided in the return message. 
The authentication service may then return an authentication credential that may allow the chent partial or fiill 
access to the space. When the client receives the authentication credential, the chent may attempt to connect to the 
space to access the documents or service advertisements in the space, 
25 The distributed computing environment may provide a mechanism or mechanisms that may enable a chent 

to connect to a space. Embodiments of a connection mechanism may provide for client-space addressing, client 
authorization, security, leasing, client capabilities determination, and client-space connection management A 
chent-space connection may be referred to as a session. In one embodhnent, a session may be assigned a unique 
session identification number (session TO). The session ED may uniquely identify a client-space connection. In one 
30 embodiment, a session lease mechanism may be used to transparently garbage collect the session if the client does 
not renew the lease. 

The following is an example of using such a connection mechanism accordmg to one embodiment A 
client may obtam an authentication credential. In one embodiment, the space may provide an authentication service 
in response to a client's request for access to die space. The cUent may obtain the authentication credential through 

35 the authentication service. When the cUent receives the authentication credential, fhc client may initiate a 
connection to the space by sendmg a connection request message. In one embodiment, the connection request 
message may mclude tiie URI address of the space service, the autiientication credential for the client and 
information about tiie connection lease the cUent is requesting. After the space receives the connection request 
message, the space may vahdate the message. In one embodhnent, an XML schema may be used to vafidate the 

40 message. The client may then be authenticated using the authentication credential- In one ^bodiment, the 
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information received in the connection request message may be used to determine the capabHities of the client to use 
the space. In one embodiment, each client of a space may be assigned its own set of capabilities for using the space. 
In one embodiment, an access control list (ACL) that may include capability Infonnation about one or more clients 
of the space may be used in client capabilities determination. In one embodiment, the infonnation received in the 
connection request message may be used to look up tiie client's capabilities m the ACL. 

After authenticating the client and determining the clients capabilities, the connection lease to grant the 
client may be determined. After the lease is determined, the structure for maintaining the cHoit-space connection 
may be generated/ A session ID for the connection may be generated In one embodiment, each client-space 
connection may be assigned a unique session K). In one embodiment, an activation space may be created and 
assigned to, or alternatively a pre-existing activation space may be assigned to, the client-space session. In one 
embodiment, an activation space may be used to stoic results of services for the client Mtoi using the space. In one 
embodiment, a client's capabilities may be used to determine if an activation space is to be created for the cUent 
For example, a client may not have capabihties to access an activation space to store and retrieve results. A message 
or messages may be sent to the client informing the client that the connection has been established The message or 
messages may include the session ID and information about tiie lease. The client tiien use tiie space including, 
but not limited to: advertisement lookup, advertisement registering, and advertisement retrievaL In one 
embodiment, he connection may remam open until tiie allocated lease expires or until the cUent sends a message 
requesting lease cancellation to die space. In one embodiment, Ac ctient may be responsible for renewing tiie lease 
before the lease expires. If tiie lease expires before the client renews the lease, tiie connection may be dropped, 
causing tiie ctient to lose tiie connection to tiie space. In one embodiment, to reconnect, tiie chent may be required 
to repeat the connection procedure. 

In one embodiment, a client of a space may obtain a space's advertisement several different ways. Some of 
tiie ways a cUent may obtain a space's advertisement are illustrated in Figure 18. For exan^le, a space discovery 
protocol may be provided as part of tiie distributed computing envnonment. Space discovery is a protocol a client 
or service may use to find a space. A Ustener agent 202 may be configured associated witii one or more spaces to 
Usten for discovery requests. The discovery listener agent 202 may listen on various network interfaces, and may 
receive eitiier broadcast requests or unicast requests (at tiie URI of tiie agent) &om cUents 200a looking for a 
space(s)- The listener agent 202 tiien responds witii tiie service advertisement<s) or URIs for tiie service 
advertisements of tiie requested space(s). In one embodiment, tiie listener agent is, in general, separate from tiie 
space, because its fimctionaUty is orthogonal to tiie fimctionality of a space service. However, tiie listener agent 
may be implemented on the same device or a different device as a space service. 

In one embodiment, the discovery protocol may be a service advertised in a default space. A cHent may 
instantiate tiie discovery protocol from tiie client's default space in order to discover additional ^aces. The 
discovery protocol may be pre-registered witii a client's default space. Alternatively, tiie discovery protocol may 
register itself witii tiie default space by placmg an advertisement in tiiat space, e.g., when a cHent connects to a local 
network serviced by tiie discovery service. 

In one embodiment, tiie space discovery protocol may be mapped to underlying device discovery protocols 
for otiier platforms, such as SLP, Jini, UPnP,.etc. Thus, a cHent may use tiie discovery protocol of tiie distributed 
computing envnonment to find services in otiier environments. A bridge to tiiese otiier environments may be 
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provided, and advertisements provided to services in these other environments so that cUents of the distributed 
computing environment described herein may access them. Refer to the Sridging section. 

For each advertised discovery protocol, the distributed computing environment may create a subsequent 
results space to hold the results of the discovery protocol hi one embodiment, space services in the distributed 
computing environment may use the Multicast Announcement Protocol (multicast UDP) to announce themselves on 
a LAN. A listener agent may record this mforaiation. A device (either a client or service) may use the Multicast 
Request Protocol (multicast UDP) to initiate discovery of a space manager. In one embodiment, the space managers 
respond Mdth infonnationindicatmg the URl of their ^^^^ Alternatively, a listener agent may respond ; 

for multiple spaces. The discovery response may abo include a short string that labels t^^ 

from keywords of the space), and information that can be used to set up a TCP connection, for example, with each 
space manager to perfonn operations on die respective space. Since the requesting device may receive responses 
from more than one space manager (or multiple space listings from a hstener agent), this mformation may help Ae 
client select which space it wishes to connect to. 

In addition to the multicast discovery described above, the discovery service may also perform discovery 
using unicast messaging (e.g. over TCP) that can be used to discover a space manager at a known address on the 
network (e.g. the hitemet, other WAN, LAN, etc). The unicast discovery message may include a request for a space 
service at a known URI to provide its service advertisement The multicast and unicast discovery protocob are 

defined at the message level, and thus may be used regardless of whether the devices participating in the discovery 

support Java or any other particular language. 

.The discovery protocol may facilitate the prolifemtion of cUents independently of the proliferation of 

server content that supports those cUents within the distributed computing environment For example, a mobile 

client may have its mitial default space built into its local platform. In addition to local services advertised in the 

default space, the mobile client may have services that search for additional spaces, such as a service to access the 

discovery protocol or a service to access space search engines. 

In one embodiment, the distributed computing environment space discovery protocol may define a set of 

XML messages and their responses that may aUow clients to: 

• Broadcastprotocol-defined space discoverymessages on then network interfaces. 

• Receive from listeners XML messages desaibing candidate spaces that those fisteners 
represent 

. Select one of those discovered spaces as defeult, without the cHent needing to know the 

address of the selected space, 

• Obtain information on the selected space, such as its address, so the cfient may later fe^ 

same space via means outside of the discovery protocol (usefiil if later the cUent wants to 
access a space which is no longer local, but w^ch stiU is of interest to the cHent). 
In some embodiments, the multicast and unicast discovery protocob m^ require an 
these discovery protocob meet the needs of devices that are IP network capable, there are many devices tiiat may 
not be directly supported by these dbcoveiy protocob. To meet the needs of such devices in discovering spaces in 
the distributed computmg enviromnent, a pre-dbcovery protocol may used to find an IP network capable agent The 
pre-dbcoveiy protocol may include the device sending a message on a non-IP network interface requesting . a 
network agent The network agent may set up a connection between itself and tiie device. Once the connection 
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between device and agent is setup.fte agent participate in the discovery protocol on IP networks onbehalf of the 
device for which it serves as agent The network agent may also provide an interface for the device to the 
distributed computing environment in general. For example, gales may be constructed in the agent onbehalf of the 
device for nmning services advertised in discovered spaces. See the lfrMfei«5 section. 

5 Another way that clients may locate spaces in the distriTjmed computing enviromnent is by adv^^^^ 

a space in another space. A space is a service, thereforeso. like any other service, it can be advertised in another 
space. As shown in Figm-e 18, a client 200b may find an advertisement 206 in a first space 204a for a second space 
204b. Space 204b may in turn mclude advertisements to additional spaces. Because a service (implementing a 
space) may also act as a client, spaces may exchange advertisements or cham together to provide a federation of 

10 spaces, as illustrated in Fignre 19. Any number of spaces may be included in the distributed computing 
enviromnent The nmnber and topology of spices may be implementation dependent For example, spaces 
hnplemented on an IP network might each correspond to a different subnet 

^ A third way a clientmay locate a space is through tunning a senrlce 208, as shown in Figure 18. A service 

208 may be nm which retams as its results the service advertisements of space services. Since service 
15 advertisements are XML documents and since the distributed computing environment may include the Internet, 
service 208 may be a Web-based search tooL An example of such a service is the space look-up service described 
in conjmiction with Figure 4. In one embodhnent, spaces within the distributed computing enviromnent may be 
implemenled as Web pages. Each Web page space may include a keyword that may be searched upon to identify 
the Web page as a space in the distributed computing enviromnent The space may include other searchable 
20 keywords as well to forther define the space. A client may comiect to a search service 208 and supply keywords to 
the search service in the fomi of XML messages. Ihe search service may receive the keywords firom the cUent and 
feed the keywords to an Intemet search engine, which may be a conventional or third-party search engine. The 
search service may return the results from the Intemet search engine to the client, either directly as XML messages 
or by reference to a results space. The results may be the UBIs of spaces matching the search request 
25 Alternatively, the search service may contact spaces identified by the search, obtain the service advertisement for 
each such space, and return the space service advertisements to the client, either dhrectly as XML messages or by 
reference to a results space. ThecUent may then select a space from the search results and construct a gate (by itself 
or through a proxy) to access the selected space. Qnce the selected space is accessed, the cUent may look up service 
advertisements within that space, which mjy lead to additional spaces. 
30 As described above, a space may be an XMI^based Website, and as such may be searched via Intemet 

Web search mechanisms. A space may include Iitonet searchable keywords. Some devices, such as small cUent 
devices, may not support an tatemet browser. However, such devices may still perform totemet searches for spaces 
within the distributed computing enviromnent A device may have a program that accepts strings of keywords, 
which may be sent to a proxy program on a server (e.g. a search service). The proxy may send the strings to a 
35 browser-based search fecilily (eg. an intemet search fecility) to perfomt the search. The proxy may receive the 
output of the search and parse it into strings (e.g. XML strmgs) representing each UW for the se^^ 
send the response strings back to the client Thus, a cUent may locate spaces through the Intemet without having to 
support a program such as a Web browser. More capable devices may avoid the use of a proxy md mitiate an 
Internet-based searcli service directly. 
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A fourth way a client may locate a space is by obtaining or receiving information about a newly created 
empty space or a spawned space when an existing space is spawned. An existing space may include an interface for 
spawning an empty space with the same functionality (e.g. same XML schema) as the space from which it is 
spawned. Spawning of spaces is further described below. 

Once a client of a space finds the advertisement of a space service, that client of the space may run the 
space service, as it would any other service. Kote that the client of the space service may be another service (e.g. a 
service seeking to advertise m die space), hi one embodiment, as ilhistrated in Figure 20, to run a space service, the 
client of the space may first run an authentication service for the space to obtam an authentication credential, as 
indicated at 300. The authentication service may be specified in the service advertisement of the space service. The 
Ghent of the space uses the authentication credential, the XML schema of the space (from space's service 
advertisement), and the URI of the space (fiiom space's serWce advertisement) to construct a gate for the space, as 
indicated at 302. ThQ client of the space may then run the space service by using the gate to send messages to die 
space service. A first such message is indicated at 304. 

For embodunents employing authentication, when the space service receives the first message from the 
client, with the authentication credential embedded, the space service uses the same autibentication service (specified 
in the service advertisement of the space service) to authenticate the clioit, thus establishing its identity, as indicated 
at 306, The space service may determine the client's capabilities and bind them to the authentication credential, as 
indicated at 308. 

As indicated at 3 10, a client of a space may run various space fecilities by sending messages to the space 
service, hi one embodiment^ when a client of a space sends a request to the space service, it passes its authentication 
credential m that request, so the space service can check the request against die cHents specific capabihties. 

Each space is typically a service and may have an XML schema defining the core functionahty of the space 
service. The XML schema may specify the cHent mterfece to the space service. In one embodiment, all space 
services may provide a base-level of space-related messages. The base-level space functionahty may be the basic 
space functionality that is capable of being used by most cUents, including small devices such as PDAs. It may be 
deshable to provide for additional functionality, e.g. for more advanced cUents. Extensions to the base-level space 
may be accomplished by addmg more messages to the XML schema that advertises the space. For exanqile, in one 
embodhnent, the base-level messages do not impose any relationsh^) graph upon the advertisements. Messages, for 
example, to travei^e a hierarchy of advertisements may be a space extension. Such additional functionality be 
provided dirough one or more extended XML space scfaemas or schema extensions for a space, Tlie extended 
schemas may include the base schema so that cUents of an extended space may still access the space as a base space. 

In one embodunent, a base space service may provide a transient repository of XML documents (e.g. 
advertisements of services, results of running services). However, a base space service m one embodiment may not 
provide for advanced facihties to support persistence of space content, navigation or creation of space structure (e.g. 
hierarchy), and a tratisactional model. A mechanism for supporting persistence, hierarchy, and/or transactions is by 
extending the XML schema. Since extended spaces still include the base XML schema, clients may still treat 
extended spaces as base spaces, when just the base space fimctionality is all diat is need or all that can be siqjported. 

In one embodhnent, the base space may be transient The base .space may be acceptable for many 
purposes. Service providers may register thek services in various spaces. In one embodiment, services must 
continuously renew leases on the publishing of uifonnation in the spaces. By this nature, the services 
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advertisements may be transient in that they may often be rebuUt and/or reconfinned. However, it may be desirable 
to provide for some persistence m a space. For example, a space that has results may provide some persistence for 
users that want to be sure that results are not lost for some tune. In one embodiment, persistence may be provided 
for by specifymg a space mterface where the client may control which objects in the space are backed by a persistent 
store and manage the maintenance of that persistence store. The persistence interfece may be specified with 
extended XML schema for the space defining the interfeces for persistence. 

In one embodiment, a base space may provide an interface where an XML document may be added to a 
space and identified by a string. Hie base space may not provide any hierarchy for the various so named XML 
documents in the space. In embodunents where hierarchy support is desked, additional interfeces may be defined 
(extending the XML schema) where the user can specify a hierarchy. Other interfaces may be specified to navigate 
the hierarchy or na^gate a relationship gr^h by position. However, o&er users may stm use the base space 
interfeces to access &ose same documents, without any hierarchy. Interfaces for oHier space structure may be 
provided for as well in extended space schemas. 

Extended XML space interfaces may also be provided for space transaction models. For example, an 
extended space XML schema may be provided specifymg an interfece for ACID transactions. ACID is an acronym 
used to describe four properties of an enterprise-level transaction. ACID stands for Atomicity, Consistency, 
Isolation, and DurabUify. Atomicity means that a transaction should be done or undone completety. In the event of 
a feilure, all operations and procedures should be undone, and all data should rollback to its previous state. 
Consistency means that a transaction should transform a system from one consistent state to another consistent state. 
Isolation means that each transaction should happen independently of other transactions occurring at the same time. 
Durability means tiiat completed transactions should remain permanent, e.g. even during system failure. Otiier 
transaction models may also be specifi'ed in extended space schemas. 

Extended space schemas may be XML documents that specify the message mterface (e.g. XML messages) 
for using extended space features, fimctionality or facilities. A space may have a base schema and multiple 
extended schemas. This may facilitate provided different levels of service to different clients depending upon die 
client authentication. 

Besides extensions for space persistence, structure, and transactions, other space extrasions rnay also be 
specified as desu^d. For example, extensions may be provided to manipulate advertisements at tiie element or 
attribute level: read, write or take advertisement elements; read, write or take advertisement attributes; and subscribe 
for advertisement event notification messages. A space may provide ^drttlally any number of fecilities and arrange 
Ihem m base and extended schemas as desired. In one embodiment, all base spaces must provide for advertisement 
readmg, writing, taking, and lookup facilities, and space event subscriptions. 

Various space facilities may be provided. In some embodhnents, a facility may be provided for the 
establishment of a session with the space. In one sudi embodiment, the rest of the space functionality is not 
available until tiiis is done. In other embodrments, the notion of a session is not provided for, or is optional and/or 
implementation dependent 

Another space fecility may be to add or remove a service advertisement to or from tiie space. A space 
facifity may also be provided for adding or removing an XML document (not an advertisement, but perhaps a result 
in a space). The space service may check for uniqueness of an item before allowing tiie addition of the item. For 
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example, each item added to the space may be associated with a user-specified string that identifies the item and that 
may be used to check for the uniqueness of the item. 

In one embodiment, a client may request a listing, tree or other representation of all services advertised in 
the space. The user then may scroll or maneuver through the advertisements and select the desired service, A space 

5 may also provide a look-up facility that allows a client to search for a service by providing keywords or string 
names. In one embodiment, a space faciHty may provide a mechanism to look up a space entty that has been added 
to the space. The look up faciHty may search by string to match for name, or wildcard, or even database query. The 
look up fecility may return multiple entries fi:om which the cHent may select one or perform a fiirther narrowing 
search. In one embodiment, the look-up facility may provide a mechanism to locate a service advertisement 

10 matchmg a particular XML schema. The cHent may indicate a particular XML schema, or part of a particular XML, 
to be searched for withm tihte space. Thus, a service may be searched for within a space acceding to 
fimctionality. 

Another space facility that may be provided in the distributed computing environment is a mechanism that 
allows services and cUents to find transient documents based upon a typing model such as XN5L. The mechanism 
15 may be a general-purpose, typed document lookup mechanism, hi one embodiment, the \ookap mechanism may be 
based upon XML. The lookup mechanism may aUow cUents and services to find documents in general, including 
services through service advertisements. 

hi one embodiment, a space lookup and response message pair may be used to aUow clients and services t» 
find XML documents stored within a network transient document store (space). The space may be a document 
20 space used to store a variety of documents, hi one embodiment, the documents are XML documents or non-XML 
documents encapsulated m XML. Spaces are finther described elsewhere herein. The lookup messages m^ work 
on any kind of XML document stored in the space, mcluding service advertisements and device driver 
advertisements. In one embodiment, a client (which may be another service) may use a discovery mechanism as 
described elsewhere to find one or more document spaces. Then, the client may use space lookup messages to 
25 locate documents stored in the space. 

The distributed computing environment may mclude a mechanism that aUows services and clients to 
subscribe to and receive events about the publication of XML documents. Events may include the pubHcation of 
and removal of XML documents to and fi-om a transient XML document repository such as a space. In one 
embodiment, an event may be an XML document tot refers to another XML document 
30 In one embodunent, a space event subscription and response message pair maybe used to aUow cHents and 

services to subscribe for events regarding documents that are added to or removed from a space. In one 
embodiment, an event subscription may be leased using the leasing mechanisms described elsewhere herein. In one 
embodiment, a subscription may be cancelled when the lease is cancelled or expires. In one embodunent, renewing 
the lease to the subscription may renew a subscriptioa 
35 In one embodiment, an event subscription message may include an XML schema that m^ be used as a 

document matchmg mechanism. Documents that match the schema may be covered by flie subscription. In one 
embodiment, any document added to a space and that matches the XML schema may genemte a space event 
message* . 

A space :fecility may also be provided to which a client may register (or unregister) to obtam notification 
40 when somethmg is added to or removed fi-om the space, A space may contain transient content, re^ 
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that at added and removed from the space. A mechanism may be provided to notify a client when a service becomes 
available or becomes unavailable, for example. A client may register with an event service to obtain such 
notification, hi one embodiment, a client may register to be notified when a service havmg a name matching a 
specified string or a schema matching a specified schema (or schema portion) is added or deleted from the space. 

5 Thus, a query to register with the space event notification faciUty may be the same as or similar to that of the service 
look up facility described above. 

When a client of a space subscribes to be notified when an XML document(s) (e.g. service advertisement) 
is added or removed from the space, the client may obtain a lease on this subscription to notifications. The lease 
may aHow the space service to know whether to continue sendmg notifications to a particular client For example, a 

10 lease to tiie notification faciUty may expire after an amount of time if not renewed. Note that a lease may not be 
required while a cfient has estabfished an active session with a spa^ 

session with a space, tiie client may continue to receive event notifications according to its event subscripdons as 
long as its correspondmg leases remam active. Refer to the Leases sectitm below. 

A client may subscribe to different types of events. Examples are a service advertisement being added or 
15 removed from a space, as described above. A client may also be notified v^on results from a service initiated by tiie 
client (or by someone else) aie put in a space. For example, tiie cHent and the service may mutually select a name 
for referring to die results of tiie service. The client may register witii the space service to which the results are to be 
posted or advertised to receive an event when a resuh referenced by tiie selected name is added to tiie space. 

A space may generate dijBTerent types of events to which a client may subscribe. As the composition of a 
20 space changes, events may be produced to those chents and services that have subscribed for such events. In one 
embodhnent, there may be two major space event categories, those that pertam to tiie space (msertion and removal 
of advertisements), and tiiose used that indicate changes to an advertisement (addmg, removmg, changing an 
element or attribute). Which events are supported may be indicated in the XML message schema for the space. 

The following events are examples of events that may be produced by a space service to mdicate a space or 
25 advertisement event: 



Table 1 



Event Name 


Type 


Meaning 


Advertisement 
Insertion Event 


AdvInsertEvent 


New advertisement has been inserted 
into a space 


Advertisement 
Removal Event 


AdvRemoveEvent 


Existing advertisement has been 
removed from a space 


Advertisement 
Element Insertion Event 


AdvElementtnserfEvent 


A new element has been added to an 
advertisemiMit 


Advertisement 
Element Removal Event 


AdvElementRemoveEvent 


Existing element has been removed 
from an advertisement 


Advertisement 
Element Gh^ige Event 


AdvElementChangeEvent 


Existing elemeiit has been changed in 
an advertisement 
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Advertisement Element 
Attribute Insertion Event 


AdvElementAttributelnsert 
Event 


A new attribute has been added to an 
element 


Advertisement Element 
Attribute Removal Event 


AdvElementAttributeRemove 
Event 


Existing attribute has been removed 
firom an element 


Advertisement Element 
Attribute Change Event 


AdvElementAttributeChange 
Event 


Existing attribute has been changed in 
an element 



Events may be typed. In some embodiments, the event fecilities supported by spaces may allow for event 
listeners to take advantage of, e.g., Java class (or XML types) hierarchies. For example, by listening for 
AdvElementEvent, the listener will receive events of type AdvElementEvent and all of its sub-classes (XML types). 
5 Thus, for this example all events pextaining to element changes {tiiough not ad^ 
received. 

By way of further example, subscribing to or listening for a top-level event class or type, e.g. SpaceEvent, 
will result in the reception of all space events. Event class types may be distinguished via, for example, the Java 
/M5fawceo/operator or the XML typing systenL 
10 An event may include a URI to the affected advertisement or element For example, AdvertisementEvent 

and all its sub-classes may contain a reference (e.g. URI or URL) to the affected advertisement AdvElementEvent 
and its subclasses may be examined for the name of the affected element. The previous element Value (URI or 
URL), may be available, for example, from AdvElementRemoveEvent and AdvElementVahieChangeEvent 

A space event type hierarchy for one embodiment is illustrated in Figure 21 . Types may be deiBned in XML 
15 and usable in Java or any other suitable object-oriented language such as C-H-, 

A space may provide a facility for a client to instantiate a service advertised in the space. Service 
instantiation is the initialization done that allows a client to be able to nin a service. On embodiment of service 
instantiation is illustrated in Figure 22. To instantiate a service, a client may first select one of the service 
advertisements published in the space, as indicated at 320. The client may use the various facilities, such as the look 
20 up facility, provided by the'space to look up the various advertisements in the space. Then the cHent may request the 
space to instantiate the service, as indicated at 322. 

In one embodiment, service instantiation may include the following actions. After the client requests the 
space service to instantiate the selected service, as indicated at 322, the space service may then verify the client is 
allowed to instantiate the requested service, as mdicated at 324. The space service may perform tiiis verification by 
25 examining an authentication credential included in the client's message. The authentication credential is the 
credential tiie client received when it established a session with the space service. The space service may verify if 
the client is allowed to instantiate the requested service according to the client's authentication credential and 
capabiUties indicated for that client See the Authentication and Security section herein. 

Assuming the client is authorized, the space service may also obtain a lease on the service advertisement 
30 for the client with the lease request tnne specified by the client, as indicated at 326. Leases are further discussed 
below. The space service may then send a message to the client which mcludes the allocated lease and the service 
• advertisement of the service, as indicated at 328. In one embodiment, the client may run an authentication service 
specified in the service advertisement and obtain an authentication credential, as mdicated at 330. See the 
Authentication and Security section herein for more mformation on an authentication service. Next, as indicated at 
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332, the client my constaict a gate for the service (for example, using the authentication credential and the XML 
schema and service URI from the advertisement). Refer to the Gates section herein. Tte above described 
communication between the client and space service is performed using the XML messaging of the distributed 
computing environment. Tlie client may then run the service using the constnicted gate and XML messaging. The 
5 servicemaysimilarlyconstructaservicegateforXMLmessagecommunicationvriththecUe^ 

To summarize, an example use of a space is discussed as foUom. A cUent may access (e.g.. comiect to) a 
space service. (A service may act as a client for the purpose of accessing or othenvise using a space.) The space 
service may store one or more service advertisements and/or other content in a space, and each of the service 
advertisements may include information which is usable to access and execute a corresponding service. The space 
10 service may inch.de a schema which specifies one or more messages usable to invoke fimctions of the space service. 
For example, the schema may specify methods for reading advertisements fiom the space and publishing 
advertisements m the space. TTie schema and sendee advertisements may be expn^ssed in an object representation 
language such as extensible Markup Language (XML). In accessing the space service, the client may send 
information such as an XML message (as specified m the schema) to the space service at an Internet address. In 
15 accessing the space service, the cUent may search the one or more service advertisements stored in the space. Tbe 
client may select one of the service advertisements from the space. In one embodiment, the client may send an 
instantiation request to the space alter selecting the desired service advertisements fromthe space. A lease may be 
obtamed for the desired service, and the lease and the selected service advertisement may be sent by the space 
service to the cUent m cUent may then construct a gate for access to the desin^d service. The desired 

20 be executed on behalf of the client. 

Another facility provided by a space service may be the spawning or creation of an empty space. This 
space facility may allow a cUent (which may be a service to another client) to dynamicaUy create a new space. In 
one embodiment, ibis space fecility may include an interface for spawning an empty space with the same 
functionality (same XML schema or extended schema) as the space from which it is spawned. This facility may be 
25 use&l for generating (e.g. dynamically) spaces for results. For example, a cUent may spawn a space a request a 
service to place results or advertise results in the spawned space. The client may pass the spawned space URI 
and/or authentication credential to the service. Or a service may spawn a space for results and pass the spawned 
space URI and/or authentication credential to the client In some embodiments, once a space is spawned, ttmay be 
discovered just like other spaces using one or more of the space discovery mechanisms described herein. 
30 By using a mechanism in wUch a space may be created via an interfece in another space (e.g. a q^^^^ 

spawning faciUty), new spaces may be created efBdently. For example, in one embodiment, storage for the 
spawned space may be aUocated using the same faciUty used by the origmal space for storage. Also, a spawned 
space may share a common service fedlity with its original (or parent) space. For example, a new URI may be 
assigned to the new space, hi one embodhnent, the new URI may be a redirection to a common space faciUty shared 
35 withtheoriginalspace.Thus,anewlyspawnedspacemayusetfaesameorsomeofthesames^^^ 

the original space. 

Space facilities may also include security admmistiation. for example, to update the various security 
poHcies of the space,.and other admrnisb^tiVe fecilides. For example, the number and age of advertisements may be 
confrolledandmonitoredbyarootspaceservice. Old advertisements may be collected and disposed. See,e.g..1he 
40 Leasessectionhereinforwhenanadvertisementmaybeconsideredold. The service implementing the space may 
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be under the control of an administrator. The administrator may set poBcy in a service dependent manner. Space 
fecilities may also include a facility to delete an empty space. 

Certain spaces inay inctade facilities or services to further support the proliferation of 

as mobile clients. For example, services in spaces that amobile client may discover, e.g. via the discoveiy protocol, 

may provide support for mobile clients, such as: 

• Assigning and administering temporaiy network addresses for the client 

Proxying message passing for the client 

Providing search fecilities for additional spaces. For example, a service may allow a 

client to specify keywords through a simple interface. The service then uses the keywords in 
conjunction with Web search engines to search for spaces on the Web, as further descnlje^ 
herein. In other embodiments, a searc* service may constram clients to seanAing onty 
supported spaces within the distributed confuting environment 
As mentioned earlier (see Figure 9 and accompanying text), spaces may provide a convenient mechanism 
for sf»ring results torn a service run by a client Usmg a space for results may allow a small client to receive in 
5 pieces the results of nnrning a service. Some services may generate a large amomit of results. By using a space to 
store the results from a service, cUents that do not have the resources to receive the fiill results at once may stfll nse 
the seivice. Moreover, by usmg a space to store results, a service nmning on a fast busy server may be fleed from 
interacting directly with a slow client when letummg large results. Thus, the service may be freed sooner for use by 
other clients. 

•0 A space may provide a convenient mechanism for accessing a result by different clients and/or at different 

times. For example, a client may not be able to use the entire result, but a user may want to access the rest of the 
■ result later usmg another cUent that can access it For example, the result could be stock quote infonnation, showing 
the current price of a stock (accessible by a PDA), and showing a chart of stock prices (accessible by a Uptop later). 
Also, using a space in the distributed computing environment for resuhs may aDow a cUentto feed the result of one 
25 servile into another service, without the necessity of downloading the result first For example, in the case of the 
stock quote information above, the PDA could feed the chart into another service, which prints the chart, without the 
PDA having to download the chart itsett Tlius, a resuhs space may provide a mechanism for a client to pass to 
another cHent or service without die client havmg to handle or receive flie results. 

In different embodfanents, the decision to use a space for results rnay be mandated by the service, mand^ 

30 by the client, and/or requested by the client A service may suggest the use of a space for its resuhs. e.g., m its 
advertisement In one embodiment, eifcer the client or the service may spawn a new space for results or use an 
existing space for results. See the description herein regarding spawning spaces. 

hi one embodiment, the use of a space for results does not necessarily mean that the service must put all 
results in that space. There may be alternatives for any result a service generates. For example, part or all of the 
35 result may be sent in-line m a message to the cUent Ahematively, the result may be put in the space, and then a 
notification message may be sent to cUent. referencmg the result (e.g. inchiding a URI to the result or to an 
advertisement for the result). Another option may be to put the result in the space, with notification via an event 
fromthespace. For example, the client and the service may agree to call the result some particular name, and then 
the client may register with the space (usmg a space faciKty such as described above) to receive an event when a 
40 result so named is added to the space. See the description above on event notification. 
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Thus, several different mechanisms may be employed vrilhin the distribu^^^ 
service to i€tum results to a cHent The a(±ial results may be returned to the client by value in an XML message, or 
results may be returned to the client by reference wiflr the actual results (or advertisement for the actual results) put 
in a space and the client receiving a message referencing the results in the space. Moreover, results, or results 
advertisements, may be placed m a space and the client notified by event. 

Mothermechanism for handling results may be for the cUent to specify another service forthei^ults to te 

fed to. For example, when a cUent runs a service that vnU produce results, the client may mstmct that service (e.g. 
flirough XML messaging) to send the results to another service for fiirther processing. THis may involve the client 
indicating the URI of an advertisement for the other service so that the result-producing service may generate a gate 
to the other service in order to mn the other service and pass it the results. In this example, the lesnte-pioducing 
service may be a client of the other service. In some embodiments, the client may send the schema or a pre- 
constnictedgatetolheiesult-pioducingservicetoaccesslheservicefor&rtherproces^ An example of a service , 
for fiirther processing is a display service that may display the results for the original client Hiis display service 
may be on or associated with the same device as the client 

Result spaces and method gates may aUow the distributed computing environment to provide a simple 
remote method invocation that is practical for thin clieiris with minimal memory footprints and minimal bandwidth, 
because it need not have the adverse side effects of huge program objects (along with needed classes) bemg returned 
(necessarily) across the network to the client as in conventional remote method invocation techniques. Instead, 
results may be retumed to a result space, and only if desired (and if they can reside on the client) are the acWal 
objects downloaded to tbe client . 

The mechanism by which the distributed computing envffomnent may provide for remote method 
invocation is as follows (refer abo to the description of method gates in the Gates section herein). An object may be 
advertised (e.g. as a service or as part of a service) in a space. Tbe advertisement includes areference that contains 
the URI (e.g. URL) of the object, along with other access parameters, such as security credentials andXML schema. 
A cUent may have or may constmct a client method gate for the object, which for every method of the object (or 
service) itself may have a wrapper method that takes the method parameters and creates a request XML message to 
invoice a method of the object The XML message is sent to a service gate that invokes the actual method on the 
service object When that method returns a result object, the service gate may post the result object in a results 
space, and m^ return a message to the client vnth areference to tiie result object 

Thus, for a cUent to invoke a remote method, the client first sends a message to instantiate an object (e.g. 
service), such as described above. In one embodiment, instantiation of an object may include the creation or 
spawning of a results space. In anodier embodiment, results space creation may be independent from the object 
instantiation. Instantiation may retmii the object URI to the cUent, and the cUent and service gates may be 
dynamically CTeated when a client requests mstantiation. In some embodiments, a results space may already exist 
and be advertised by the object (service). Some part or all of the gates may also have been pre^nstructed or 
reused- 

Once a cKent has mitiated an object, a local caU of the appropriate client method gate wiU aff^ 
call to the actaal remote object, as described above. The remote method invocation approach of the distributed 
computing environment may be recursive, with object references retumed to the client, instead of the objects itselt 
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when the client gate is caUed. Note that such returned objects may akeady be instantiated. In some embodiments, 
the client may make a decision to download an entire object itsel£ rather than just remotely invoke it 

A method or service invoked as described above may generate a child gate that is associated with the 
results document The method may return a child gate (or the schema, URI and credentials for the client to construct 
5 a child gate) for the references instead of the references themselves. Hie client may then access the references 
through the child gate. The child gate may also be a method gate. 

As described above, this remote method invocation provided by the distributed computing environment 
allows the real result object(s) to be stored in a service results space (yduch also may be created dynamically, by a 
servlet for example). The results space may be temporary. The results space may act as a query results cache. The 
10 results cache may be patrolled by server software (garbage collector) tiiat cleans-up old result areas. Distributed 
garbage collection may be employed, as result spaces may fill up until they are destroyed by a client mdicating it no 
longer needs the space, or by an administrator on a server setting ^propriate limits. 

Turning now to Figure 23, an illustration of a default space 350 is provided. The distributed computing 
environment may prowde at least one defeult space so clients can find an initial set of advertisements. A device may 
15 have a default space that exists locally, with a built-in pre-constructed gate. The services advertised in that default 
space may exist locally on tiiat device, and they may provide system software that enables or facilitates the device*s 
participation in the distributed computing enviromnent 

The defeult space 350 may include one or more mechanisms 352 to locate external spaces, as shown in 
Figure 23. One service in the default space may run the space discovery protocol described above to find external 
20 spaces. Also, external spaces may be advertised in the default space. Additionally, a service (e.g. a search engine or 
a proxy service to a search engine) may be advertised in the default space tiiat determmes or finds external spaces. 
Each space may be analogous to a ffle system mount point Thus, the distributed computing environment may 
provide searchable, dynamic mount points to services. A default space may be a client* s initial moxmt pomt to the 
distributed computing environment. 
25 A defeult space or access to a defeult space may be built in to a device. Through the defeult space and 

local services that may exist on the device, a client execution environment for the distributed computing 
environment may be provided. A device's local services and default space service may have built-in pre-constructed 
gates. One of the built-in services Usted in tiie defeult space may be a service to run the discovery protocol so that 
the client may locate additional (e.g. external) spaces. A default space may include a built-in service that provides 
30 an execution environment for clients tiiat allows the chent user to browse spaces, select, and then mstantiate 
services- Such a service may provide a simple user raterface that allows a cUent to entire strings (e.g. keyword for 
space searches), view or browse result references (e.g. space listings, or service listings within a space), select items 
(e.g. to chose and instantiate a service), etc. 

Devices that primarily provide a service may also include a defeult space and may include a built-in service 
35 in the defauft space that allows a service to manage advertising itself in various spaces. For example, a device, such 
as a printer, may have a built-in default service tiiat finds (perhaps tiarough tiie discovery protocol) a space on a local 
area network and adds an advertisement for tiie printer service to that space. This service may also mamtain tiie 
printer service advertisement witiun the LAN space, for example, by renewing its lease or updating tiie printer's 
XML schema, etc. 
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For some devices that provide a service, the overhead of finding a space to advertise its service and 
maintainthatadvertisementisundesimble. In one embodimenVrather than searching for and maintaining a space or 
spaces to publish service advertisements, services on some devices may transmit their advertisements in response to 
connectionreqaests. ForexampIe.aprinterdevicewilhaprinterservicethatisavai^^^^^ 

5 not maintain an advertisement in a space (on the device or external to the device). Instead, when another device 
establishes a connection with the prmter device (for example, a user with a laptop rumimg a 
document), the printer service may transmit the service advertisement to provide the XML service schema for 
connecting to and running the service that provides printing functionality on the printer device. Also, some devices 
may only maintain advertisements for their services in a certain vicinity or locd 

1 0 desire to support or may not have access to transports for broader accessibiUty. 

One example of a service device in vvWch h may be desirable for the device to avoid or limit nmm^^ 

serviceadvertisementsinaspaceisadevicewhosetoctionalityisavailableonaproxhnilybas^ 
servicesmaypiovideadvertisementsoftheirflmctionaHtyuponrequest n»ese advertisements may not be broadly 
accessMe. For example, proximity-based services may be provided ma wireless communications system Thetenn 
15 "wireless" may refer to a commmiications. monitoring, or control system in which electromagnetic or acoustic 
waves carryasignal through atmospheric space rather than alongawire. In most wireless 

(RF) or inihued (IR) waves are used. Typically, m proxhnity-based wireless systems, a device compnsmg a 

bansceivermustbewithinrange(proximity)ofanotherdevicetoestablishandmaintamac^^^^ 

A device may be a hub to connect other devices to a wireless Ix)cal AreaNetwork (LAN). 

As mentioned, embodhnents of the distributed computing enviroranent may provide a mechanism using a 
lookup space that allows clients to rendezvous with services. In a proximity computing environment, one 
embodiment of the distributed computing enviromnent may provide a service discovery mechamsm that cli^^^ 

use to discover services without using lookup spaces as rendezvous pomts. An example of a proximity computmg 
enviromnent is an IrDA point-to-point communications enviromnent In a proxhnity computing enviromnent, the 
proximity mechanism may find the "physical" location of the service for the client. For example, m an IrDA 
enviromnent. the cUent device rnay be physicaUypomted at the device including the service© 

to use. 

The proximity service discovery mechanism may enable the client to directly look for service 
advertisementsratherthanse„dingalookuprequesttoalookupspacetolook& Sincethe 
cUent device may have estabUshed a proximity connection to the service device, the cUent may directly reques^^ 

desired service. For example, a PDA client device may establish a proximity comiection to a prmter device; the 
client may "know" to request a printer service connection on the printer device. 

' In one embodiment, the client may send a pmximhy service discove^^ message to the service device. The 
message may include information that may specifyadesired service on the service device to which t^^ 

35 has a proximity connection. Jn one embodiment, a service on the service device may respond to the proxmuty 
service discovery message, and may send to the cUent the service advertisement that the cUent nu^ 
the desired service. Tie proximity service discovery message may also include information that my be «s«^ 
authenticate the cUent and to establish the cUent's capabiUties on the service. Using the received service 
advertisement, the client may establish a gate to estabhsh commmiication with the desired service. 
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Nevertheless, it may stiU be desirable to publish advertisements for services to do not desire to or camiot 
maintaintheiradvertisementsinaspaceihatisbroadlyaccessible. In one embodiment of a distributed computing 
environment, a device that establishes a comiection with a device that does not publish its service advertisement(s), 
such as a proxhnity-based device, may publish service advertisements received from the non-publishmg device. For 
example, a device that establishes a comiection mth a proximity-based device and that has an alternate transport 
com»ection(s) may publish (or republish) service advertisements received from the proximity*ased device in the 
alternate transport enviromnent. thus aUowing the proximity-based device service(s) to be used by other devices 
(throughthe(re)pubUshedserYiceadvertisements)v»Uchareoutsidethenormalproxto^ 

Thepublishingdevicemaylocatealocdlypublishedserviceadvertisementfortheproximity-basedde^^^ 

toough a discovery and/or lookup service, or alternatively the service adverti^^ 

local service device, but instead may be sent to the publishing device by the local device upon the establishment of a 
comiection. as described above, one embodiment, the republished service advertisement may be made available 
as long as the device maintaining the advertisement is comiected to or able to connect to the local device. For 
example if the publishing device is discomieaed from the local device (for example, moves out of proxumty range 
of the device), the service advertisement may be made stale or removed. A lease mechanism may be provided to 
allow the space containing the advertisement to send lease renewal messages to the publishing device. Th. 
pd^lishing device may verify its connection to the local device, thus allowing the space to detect when the local 
device is no longer available. Rules for how the service advertisements are republished may be provided by the 
local device or by an administrative policy for the local vicinity (eg. proximity area) or local network. 

Figure 24 illustrates an example of a device bridging proximity-based devices onto another transport 
mechanism to allow the services provided by the pmxhnity-based devices to be accessed by devices outside the 
proximity range of the devices, according to one embodiment A publishing device 1404 may be «mBected to a 
network 1412, such as an Ethemet LAN ortheMemet, etc.. and may establish and maintain proximity com»ections - 
1414 with proximity devices 1400 and 1404. Proximity comiections may be wireless comiections or wired LAN 
comiections. for example. Proximity devices 1400 and 1402 may each send a service advertisement to the 
publishing device 1404 upon comiection, or. alternatively, the publishmg device may locate the service 
advertisements usmg a discovery and/or lookup service for the proximity connections. T^^ 

may then make the services provided by the proximity devices available to other devices 1408 and 1410 on the 
networkl412byi.publishingtheserviceadvertisementsl4l6midl418mspacel406. Space 1406 may be stored 
onthepublishin6deviceoronotherdevicescom.ectedtotheLAN(includingdevicesl408andl410). 

OflierdevicesonthcLANincluding devices 1408and 1410 may then discover space 1406 and look up the 
republished service advertisements 1416 and 1418 for the p,t>ximity-based devices, establish gates to communicate 
to those services (device 1404 may act as a proxy or bridge) on the proximi^-based devices 1400 and 1402 usmg 
the XML message passing methods described previously, and send requests and receive results to the pioxnmty 
devices. Publishing device 1404 may act as a bridge between the networic 1412 and the proximity comiections 1414 
to the proximity-based devices. 

~ Leases may be used in the distributed computing enviromnent to deal with partial feilure, resomx=e 
syndronization (scheduling), and to provide an onlerly resource clean-up proc^^^^ Leases may help the overall 
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distributed system manage independent clients and services that may come and go. The various resources that 
clients obtam from services (including space services) may be leased from those services, hi general, not every, 
resource can or needs to be leased In one embodiment, it is up to the implementation of each particular service to 
determine which of its resources need to be leased, hi particular, resources used by a large amount of clients 
5 simultaneously may not need leasing or instead may require custom leasing protocols. This class of leasmg may be 
left to the service provider. Custom protocols, such as those to hnplement transactions for example, may be built 
upon the base leasmg scheme. In one embodiment, the base leasing model is a relative time-based model. 

Services may issue leases to clients and provide operations on tiiose leases. In one embodiment, all such 
lease functionahty of a service is part of that service's XML schema. Thus, a cHent may use its gate (correspondmg 
10 to the service and constructed for Ifae service's XML schema) to perform lease operations. In one embodhnent, all 
smices that issue leases provide the foUowmg lease operations (only aUowed by the owna: of the lease): (i) 
renewmg a lease (parameters specified: lease' (e.g. lease ID, lease credential), new lease time requested), and (li) 
canceling a lease (parameter specified: lease (e.g. lease ID, lease credential)). In one embodiment, all leases are 
granted for a particular amount of relative time (duration of lease) that may be negotiated. The requestor may 
15 specify a certain amount of time (e.g. m seconds), and the grantor may grant the lease for any amount up to that 
time. In one embodiment, a -1 value may be used to specify an indefinite lease. 

In one embodiment, a service advertisement may include one or more leasing addresses, hi one 
embodiment, the leasing addresses may be URIs. Standard leash^ messages to renew and cancel service resource 
leases may be sent to a leasing Uia. An example lease URI: 
20 <leaser>servicel://resourcel<yieaser> 

An advertisement may also include various leasmg messages as described above. Leasmg messages may 
include messages to renew and cancel leases for resources of the service. In one embodiment, the messages may be 
comprised ia an XML schema in the advertisement 

The leasing mechanism may provide a mechanism to detect service and cUent failwe. Leases may also 
25 provide a mechanism to provide shared and exclusive resource access. In one embodhnent, all service resources 
either have no lease (resource is not leased and therefore available), a shared lease (resource accessed by multiple 
cHents), or an exclusive lease (resource is accessed by exactiy one client at a time). In one embodiment, all 
resources begin in tiie no lease state. A no lease state signifies tiiere is no current access to the underl>ing resource, 
and mdicates that tiiere is an interest m the resource remaining in existence and thus available for leasing. The 
30 leasing level may be mcreased from none to shared, none to exclusive, or shared to exclusive. Lease isolation levels 
may also be decreased from exclusive to shared, exclusive to none, and shared to none. In one embodiment, clients 
may voluntarily mcrease or decrease the lease isolation level, or may be requested by tiie service to do so. A 
response message from the service may mdicate if the isolation level change was accepted. 

Request-response message pairs may be employed to claun, release, and renew a lease. Each message may 
35 be tagged using a reserved XML tag to mdicate that the message is a leasmg mess^^^ The distributed computing 
environment doesn't necessarily define the complete composition of the message. In such an embodiment, service 
developers niay append custom message content, as long as, the message is tagged as a 

In one embodhnent, clients that use leased resources ma^^ be expected to: (i) claim the resource as shared or 
exclusive, (ii) release tiie resource claun (if requested or if finished witii resource), and (in) respond to renewal 
40 messages (with another claim at same or difierent isolation level). Renewal messages may be sent (e.g. in regular 
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intervals) by services to detect client failure cases. The interval (at wUch the renewal message is sent) may be 
service specific. If a response to the renewal message isn*t issued after a specific amount of time (e.g. based on a 
time noted in the service advertisement), a resource reclamation process may begui within the service, revokmg the 
lease completely. In such an embodiment, renewal messages sent to clients should be handled in a timely fashion. 
Figure 25 illustrates the use of renewal messages both between a client and an instantiated service and between a 
service provider and a space service. Note that both cases may be considered as the use of renewal messages 
between a client and a service, since a service provider may be a client to a space's advertisement service. 

Renewal messages may arrive in an "out of band'' fashion that may be inconvenient for the client to handle. 
That is, the client cannot predict when a renewal message will be sent from the service. Out of band message 
handling may complicate the client's logic and increase its complexity. To solve this problem, an automatic lease 
renewal mechanism m^ be implemented to relieve the client of the responsibHity of handling the out of band 
messages, and thus reduce client complexity. In the automatic lease renewal mechanism, each gate (message, 
method, and/or event gate) may receive renewal messages and automatically respond to them without help from the' 
client The default response to a renewal request is to claim tibe lease at its current level Each message gate may 
contam a single, set-aside renewal response message that is automatically sent to the advertisement space service 
when tiie gate receives the renewal message. This "out of band"' message is haiidled on behalf of the client, yielding 
a cleaner client programming model. In one embodiment, the gate may allow clients to reg^sta: lease event handlers 
to specify different isolation levels in the response message. 

The leasing mechanism may also provide a mechanism to detect stale advertisements. When a service 
■ publishes its advertisement in a space, that service obtains a lease on tiiis publishmg of its advertisement Each 
advertisement may contain a time by which the service promises to renew the advertisement In one embodiment, 
all time-out values are specified in seconds. If the service continues to renew its lease, the space is provided some 
assurance that the service advertised is still being offered. The renewal time may be counted down towards zero by 
the space service. If the service does not renew its lease, the service may have fafled, or it may no longer wish to, or 
be able to provide the service. When the lease is not renewed, tiie space service marks the service advertisement 
stale, so it does not make it available to clients. Services renew advertisements by sending a renewal message to the 
space. The space service receives these messages and resets the advertisement renewal time back to its initial value. 

In one embodiment, stale advertisements are not automatically deleted. Depending upon the policies of the 
space, it may choose to delete stale service advertisements that have expired for a reasonably long period of time. 
The deletion policy may be set by tiie space service. The space service may search for stale advertisements and 
either delete them or bring them to the attention of an admiriistrator, for example. 

A space service noay use leases to manage the resources its facilities provide to clients (including other 
sendees) of the space. For example, when a client deskes to use a service, ^e space service may request a lease for 
the client as part of service instantiation. Service instantiation may be performed to allow a client to run a service. 
To instantiate a service, a client may first select one of tiie service advertisements published in a space. The client 
may use die various facilities provided by die space to look advertisements in the space. Then the client may 
request the space to instantiate the service. The lease acqmred during service instantiation is on use of the service 
advertisement (not the same as the lease on publishmg of the service advertisement). It should be noted that the 
space service may aUow multiple cUents to have a lease on use of a service advertisement if the advertisement has an 
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indication it is shared Otherwise, the space service only allows one client at a time to have a lease on the service 
advertisement (exclusive). 

Another example of how a space service may uses leases to manage flie resources its facilities provide to 
clients is when a client of the space registers to be notified when XML docnmaits (e.g. service advertisements) are 
added or removed from a space. The registering cUent of the space may obtain a lease on this subscription to 
notifications. This lease enables the space service to know wAether to continue sending notifications. Such a lease 
may not be necessary when a client has established an active session with the space. Also, note that when a client of 
a space (could be a service) establishes a session with the space, the client may obtain a lease on fte session. This 
allows tiie space to manage any resources associated with tiie session. 

In another embodiment, the distributed computing enwonment may employ a leasing mechanism tiiat is 
nottime-based. The lease may be generated when an object is claimed for use. Instead of a time-based mechanism, 
the claim method may accept a callback that notifies the current leaseholder tiiat some other party wishes access the 
same object (e.g. service). Thus, as an alternative embodiment to time-based leases, instead clients may make 
claims on space objects (e.g. seivices). When another cUent desires a lease tiiat is incompatible with tiie current 
leaseholder's lease, tiie service may send a "caflback message" to tiie client Upon receiving flie caUback message, 
flie client (i.e. client gate) may invoke a callback method to decide on a response to flie callback message (keep flie 
lease, cancel tiie lease, change the access level to shared, etc.). Once a response has been detemiined, tiie client gate 
sends a response message to tiie service. This distributed mechanism for managmg leases be implemented 
using the XML message-passing layer. 

For a non-time-based lease embodiment, flie distributed computing environment may provide lease support 
for several levels (or kinds) of access ttiat allow a distributed algoritiim to detennine lease con^>atibility. Those 
levels may include: (i) keep tiie object in flie space (keepInSpace). (ii) read tiie object in flie space (readShared). and 
(iii) read exclusively the object in the space (readExclusive). 

Authentication and Security 

The distributed computing environment provides for spontaneous and heterogeneous distributed systems 
based upon an asynchronous message passmg model, where data and/or objects may be represented hi a 
representation language such as XNIL. In the distributed computing environment. cUents may connect to savices 
fliroughout flie Internet, for example. The distributed computing environment may enable large numbers of network 
devices to work togeflier in a reUable, dynamic, and secure fashion. The distributed computing environment may 
define a protocol tiiat substantially enables interoperability between compUant software components (cUents and 
services). 

In flie context of flie distributed computing environment, a device may be a netwoikmg transport 
addressable unit Clients and services may be implemented as Universal Resource Identifier (URI) addressable 
instances of software or firmware fliat run on devices. 

Internet space is inhabited by many points of content A UM is a mefliod used to identify any of tiiose 
pohits of content, whetiier it be a page of text, a video or sound clq), an image, software, finnware or oflier Internet 
content The most common form of URI is flie Web page address, which is aparticular form or subset of URI caUed 
a Uniform Resource Locator (UKL). A URI typically describes flie mechanism used to access flie resource, flie 
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specific computer that the resource is housed in and the specific name of tiie resource (typically a ffle name) on the 
computer. 

Clients and services (both may be implemented on devices as software and/or firmware) may be connected 
over the Internet, a corporate intranet, a dynamic proximity network, within a single computer, or by other network 

5 connection models. The size and complexity of the devices supporting clients and services may range, for example, 
fi-om a simple light switch to a complex, highly avaDable server. Example devices inchide, but are not limited to: 
PDAs; cellular phones; notebook, laptop, and more powerfiil PCs; and more powerfiil computer systems, up to and 
including supercomputers. In some embodiments, the distance, latency, and implementation of clients and services 
may be abstracted, with a common discovery and communication methodology, creating a "black box" effect This 

10 definition approach allows software unplementation issues to be dealt with by the underlying platform, yielding a 
loosely coupled systrai that may be scaled to Internet proportions. 

The distributed computing environment may provide an Internet-centric programming model includmg 
WEB and XML content representation, dynamic device discovery, and secure de^dce communication that is 
accessible from a wide range of network devices. The distributed computing environment may mclude a network- 

15 progranmimg model abstracted above the CPU levd. The programmm 

• URI addresses 

• Strongly typed data called content (addressed vrtthURIs) 

• Substantially unlhnited amount of persistent content storage (e.g. stores), (contammg XML and non-XML 
content, such as that identified by MIME types) 

20 • substantiaUyunlimhed amount oftransient content memoiy called spaces (containing XML conte^^^ 

• Descriptive XML metadata (data about data) content advertisements that may be stored in a space to notify 
interested clients. 

• A substantially unfimited number ofinstructions (embodied as messages) 

• Secure message endpoints (gates) addressed by URIs 

25 • Data flow support (event messages) to coordinate workflow between distributed sofbfvareprog^ 

Services and clients may run as programs within the distributed computmg environment Services may 
advertise their capabilities to clients wishing to use the service. Clients m^ or may not reside wiAm the same 
network device, and that device's code execution environment may or may not support the Java platform. 

Usmg URIs to address content and message endpomts gives tiie distributed computing environment a 
30 powerful addressing scheme. The address may specify the location of the content or endpoint, and may specify the 
route (or transport protocol) to be used. Items addressed using URIs also may have an associated security 
credential The security credential may be used to control what clients are ^owed access to the item, as weU as 
which operations authorized clients are allowed to perform on that item. 

The high degree of access provided by the distributed computing environment may be controlled by 
35 appropriate authentication and security systems and methods. Audientication and security in the distributed 
computing ^vironment may include, but are not Umited to: verifying tiie typing correctaess of XML content in a 
message; secmety identifying the sender to the receiver; a mechanism to check integrity of 
client to a service and vice versa; and a mechanism of describmg a service's set of accepted messages to a cUent and 
enforcing the message requirements on messages received at tiie service. The above listed security and 
authorization features may be leveraged in a single, atomic unit of code and data. The atomic unit of code and data 
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may be dynamically created. In one embodiment, once created, the atomic unit of code and data may represent a 
message endpoint (gate), and may not be altered as to tiie security and authorization policies implemented during 
creatioiL 

A gate may represent the authority to use some or all of a service's capabilities. Each capability may be 
5 expressed m terms of a message that may be sent to a service. Gates may also be used for failure case detection 
when a client leases resources. 

Autiientication and security may also include a mechanism for verifying that a client attempting to use a 
service is authorized to use the service; that the space from which the client receives the service advertisement from 
is authorized to provide the service adverdsement; and/or that the service advertisement itself is authorize 
10 Message passing may be implemented in a messaging layer as the means of communicating requests from 

clients to services and of ihe services responding with results to the clients. The messaging layer of the distributed 
computing environment may substantially guarantee that valid XML messages are sent, and may provide 
mechanisms enabling a language-mdependent security model In the messaging layer, a sending message en<^oint 
may be linked to a receiving message endpoint The two associated message endpoints may provide a secure, 
1 5 atomic, bi^ectional message channel suitable for request-response message passing between a client and a service. 

In embodiments of a distributed computing enviromnent, an advertisement may be published in a space for 
a service. An advertisement may be an XML document that includes the XML schema and XIRI of the se The 
service may also include a service ID token or credential in the advertisement, and may specify in the advertisement 
an authentication service to be used by both the client and the service. A cHent may then locate the service 
20 advertisement on the space, and use the advertisement to instantiate a message gate on tbe cHent The client may use 
the authentication service specified in the advertisement to obtain an authentication credential for sending in 
messages to the client. In one embodiment, ^e client may pass tiie service ID token or credenti^ from the service 
advertisement to the authentication service, and the authentication service may then use the service token or 
credential to generate the auUientication credential for the client In one embodiment, the client may include a gate 
25 factory that receives the necessary information to create the message gate, and the gate factory may construct the 
message gate and communicate with the authentication service to obtam the authentication credential for the client 
A corresponding service message gate may be instantiated at the service. 

The client, at some point, sends a first message to the service. In one embodiment, the client message gate 
may embed the client's authentication credential constructed by the authentication service m the message. When the 
30 service receives the message, it may use the same authentication service to verify the authentication credential 
received in the message. By sharing the same autfientication service, any of a variety of authentication protocols 
may be employed, with the details of generating the authentication credentials separated from tiie client and the 
service. Thus, a client may use different authentication credential protocols witib different services. 

In one embodiment, the authentication service may determine tiie capabilities of the cli^t (e.g. what the 
35 client is allowed to do on the service) upon first receiving the client authentication credential fix)m the service. The 
capabilities of the client may be bound to the client's identify. Then, the client's message gate m^ embed tiie 
authentication credential in every message sent from the client to tiie service. The messages may be received by the 
service message gate and then checked by the authentication service to ensure that the message is from the client and 
that the message request is within the capabilities of the client. In anotber embodhnent, the service message gate 
40 may handle capability determmation and message checking for capabilities without using the authentication service. 
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The client and service message gates may woric together to provide a secure and reliable message chamieL 
The gates may serve as secm-e message endpoints that allow tiie client to nm the service by sending and receiving 
secured, authorized XML messages to and from the service. 

Operations in the distributed computing environment may be embodied as XML messages sent between 
clients and services. The protocol used to connect clients with services, and to address content in spaces and stores, 
may be defined by the messages that can be sent between the clients and services. The use of messages to define a 
protocol may enable many dijBferent kinds of devices to participate in the protocol. Each device may be free to 
implement the protocol in a manner best suited to its abilities and role. 

A service's capabilities may be expressed in terms of the messages the service accepts. A service's message 
set may be defined using an XML schema. An XML message schema may define each message format using XML 
typed tags. The tag usage rules may also be defined in ttie schenaa. The message schema may be a component of an 
XML advertisement along vntii the servicers message endpoint (gate) used to receive messages. Extensions (more 
capabilities) may be added to services by adding messages to the XML message schema. 

In the distributed computmg environment, authorized clients may be able to use all of a service's 
capabilities, or may be limited to using a subset of the service's capabilities. In one embodnnent, once a set of 
c^abilities has been given to a client, the client may not change that set without proper authorization. This model 
of capability definition may allow for services levels that run from a base set of capabilities to an extended set 

Service instantiation may be performed to allow a client to run a service. To instantiate a service, a client 
may first select one of the service advertisements published in a space. The client may use the various fecilities 
provided by the space to look up advertisements in the space. Then the client may request the space to instantiate 
the service. Service instantiation may include, but is not limited to, the following steps: 

1. Client requests space service to instantiate a service. 

2. Space service verifies client is allowed to instantiate the service. 

3. Space service obtains a lease on the service advertisement for the client with the lease request 
time specified by the client. Alternatively, the service advertisement may be provided to the 
client without using the leasing mechanism. 

4. Space service sends a message to the client that includes the lease allocated in steps 3, and the 
service advertisement of tiie service. 

5. CUent runs the authentication service specified in the service adverdsement, and obtains an 

authentication credentiaL 

6. Client constructs a chcnt message gate for conmiunicating with the service. 

In order to provide trust between clients and services in liie distributed computing aivironment, a series of 
dynamically generated numbers (keys, or tokens) may be used as security or authentication credentials for clients. 
One or more credentials may be used to verify the rigiit of a client to use a sendee and to verify messages between 
the client and the service. Each client and service may have a unique credential. 

The type of authentication credential needed to use a service may be returned to the client conducting a 
service search. In one embodiment, an authentication credential is an opaque object that must be presented each 
tune a client uses a service. In one embodiment, the authentication credmtial may be presented by a message gate 
on behalf of a client in every message sent to a service. No matter what kind of autiientication credential is required 
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by a service, by using an authentication service external to the client and the service, the client and the service may 
not need to be aware of the authentication credential structure or of the authentication process. 

An authentication credential may also include a transport-specific ticket in addition to the service ticket. 
When running a service, depending upon the networking transport specified in the service advertisement, the 
transport may provide a secure connection. In some cases, if the data link layer is already secure, it may not be 
necessary to use a secure transport over the already secure data link layer. 

The concept of an authentication credential is abstract enough to allow various levels of security based 
upon credential implementation. Levels of security may include, but are not limited to: 
L None (no message security -credential is empty or no credential) 

Messages with empty credentials or no credentials may be sufficient y/hen security is enforced 
by the physical connectivity properties of the transport For instance, a smart light switch 
coimected to just one light switch controller is secure because tiie swtches are wired in a 
secure manner. 

2, Signed messages (digital signatures) 
Signed messages may include a digital signature that enables the service (receiving tiie 
message) to verify the ori^ (client) of the message. 

3, Encrypted messages (transport may handle this) 
Encrypted messages add another level of security by scrambling the message contents so that 
another credential is required to imscramble it 

4, Capability messages (service fttnctionaiity and user aware) 
This level of security may provide for security capabilities on a user-by-user basis (e.g. what 
the user is allowed to do), and may allow for fine-grained access control to services and 
individual service functions. 

Multiple levels of security zones may be used, due to the heavyweight implementation necessary to enforce 
25 the higher levels of security (c^abilities & encryption). If tiie message transport supports (or helps support) these 
security levels, the support may be leveraged to provide security level bridge services tiiat bridge one level of 
security to another. 

As mentioned above, services without any security model may accept empty authentication credentials. For 
services that do not restrict access, a gate may be built without an authentication credential or with an "empty" 
30 authentication credential The gates for such services may not send an authentication credential with each message, 
or may send an empty credential The aiitiientication service is one example of a service that may not restrict access. 
Other services may require a user and password pair. 

\ ■ ■ ■ 

Authenticating Service Access using Credentials 

35 In some embodiments, a mechanism for verifying that a client attempting to run a service is an authorized 

client, for verifying that the service advertisement received by the cHent is an authorized service advertisement, 
.and/or for verifying that the space from which the client received the service advertisement is authorized may be 
based upon a public key/private key asymmetric cryptographic mechanism. In this mechanism, an authorized 
sending entity may embed a public key in a message and encrypt the message includmg the public key with its 

40 private key. An entity receivmg the encrypted message may decrypt the message using the pubhc key and find the 
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same public key embedded in the decrypted message, and thus verify &at the message is from the authori:^d entity, 
smce only that entity has the private necessary to encrypt the message. Thus, an entity may issue a credential 
that is substantially unforgeable, and that other entities may decrypt (with the appropriate public key) to verify 

messages sent by the entity. 

Various key generation algorithms may be used in the distributed computing envuronment The 
composition of keys may be hidden from both cHents and services; thus, the cHent and service may not care what 
key generation algorithm is used. 

A Kerberos ticket is one example of a security credential that may be used in the distributed computmg 
environment Kerberos is a secure method for au&enticatmg a request for a service in a computer network. 
Kerberos lets a user request an encrypted "ticket" from an audienti^^^ 

particular service. The user's password does not have to pass through the network. 

Mechanisrns may be provided by the distributed computmg envkonment to sub^^ 
messages sent between clients and services are not compromised. In one embodiment, a sender may embed a token 
contaming mformation that may be used by the receiver to verify th^ the message has not been altered. There are 
5 several methods for generating the information to embed in the message. In one embodiment, a hash of the message 
may be computed and sent with the message. Hashing may mclude the transformation of a string of characters into a 
usually shorter fixed-length value or key that represents Ae original string. Upon receiving the message, the 
receiver may recompute the hash and check it against the sent hash. If the message has been altered, it is highly 
unlikely that the same hash will be generated. Hie sender may encrypt the hash and send the correspondmg public 
20 key m the encrypted message to substantially ensure that the bash is not compromised. 

In other embodiments, an error detection scheme such as cyclic redundancy checking may be used. CycUc 
redundancy checking is a method of checldng for errors in data that is transmitted on a communications link. In an 
embodhnent using cyclic redundancy checkmg, the sender applies an n-bit polynomial to the message and appends 
the r^ulting cyclic redundancy code (CRC) to the message. The receiver ^pUes Hie same polynomial (which may 
25 also be passed m the message) to the message and compares its result with the result append Ifthey 
agree, the message has been received successfully- If not, the sender may be notified to resend the message. 

Gate factories may also play a role m security, smce a gate factory may be ."trusted" code. Usmg a trusted 
gate factory to generate gates may help to eaisure that gates are trusted code, and that the code is correct with respect 
to the service advertisement Clients may be required to present a cUent ID token or credential to the gate factory as 
30 a means of audientication. Ser>dces may present a service ID tok^ or oredential to cUents (e.g. toough an 
advertisement) when a client wishes to create a gate. As discussed herein, a client and service token pair may be 
used to create a tiiird credential that may be used to aUow the cUent to send messages to the service. This third 
CTcdential may be referred to as an authentication credential. An authentication credential may be created by an 
authentication service durmg the authentication process. In one embodiment, the service may use any authentication 
35 poHcy at its disposal In one embodhnent, the audientication service admmisters the authentication policy on behalf 
of the service, and thus the service does not have to be aware of the particular authentication poUcy bemg used. 

The client may construct its gate using an authentication credential tiiat the cUent receives by runnmg an 
authentication service specified m the service advertisement This may aUow the constructed gate to send the 
authentication credential with each message to the service. When the service receives the first audientication 
40 credential in a first message from the cUent, the service may use die authentication service specified in the service 
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advertisement to authenticate tiie cKent, and thus may establish a binding of the authentication credential to the 
identity of the client 

As previously discussed, some results produced by a service may be advertised in a space and ultimately 
accessed using a results gate. The results gate may or may not contain the same security credential as the input gate 
5 used to generate the results. Because input to a service may be asynchronous from its output (the results), the results 
may have a different set of access rights associated with it For example, a payroll service may allow a different set 
of clients to initiate payroU than to read the payroU service's results (paychecks). Hius, a client may have to go 
through a separate authentication process to obtain access rights to the results, which may include receiving an 
authentication credential for the results from an authentication service specified in an advertisement for the results. 
10 Message gates may offload most security checks fi^m services. Services may focus on providing c^ability 

and authenticating cHents. A princ^le of least privilege may be supported by giving cUents access to only those 
capabilities that are requested (or assigned). 

Security checks may occur when a gate is created and/or when a gate is used (when messages are sent 
and/or received). When a client requests access to an advertised item (service), the process of gate creation may 
15 begin. During this process, the client gate factory may work with the service to mutually authenticate each other. 
The checks perfonned at gate creation time may be extensive, and may niininiize the nvmiba* of checks perforaied 
during gate usage. After the service has audienticated the cUent, the sendee may detennine specific 
the client (e.g. what the client is allowed to do on the service), and associate the capabilities with the chent's 
authentication credential. These specific capabilities may specify what operations the client is allowed to perform 
20 on the service. Since the gates may ensure that every message cont^ the authentication credential, the service can 
then check each request when it is received against the capabQities of tiie authenticated client 

Gate creation checks may ensure that a client has permission to use some or all of tiie service capabilities 
designated by the XML message schema. In one embodiment, tiiese checks may be implemented usmg access 
control lists (ACLs) m conjunction with an autiientication service such as Kerberos. A challenge-response sequence 
25 (such as a password) may also be used to authenticate a cUent to some embodiments, a hardware-based physical 
identification method may be used to authenticate the client For example, tiie user may supply a physical 
identification such as a smart card for identification and authorization. Other mechanisms for authentication may be 
used in other embodiments. 

In one embodiment, whatever means is used to authenticate the client, the authentication may be invisible 
30 to both the client and service, the gate fectory may be aware of which authentication service to use, and the 
authentication service handles the autiientication mechanism and policies. Gate factories may be product and 
environment dependent, or mey even be controlled by a configuration management system. In one embodhnent, the 
degree and method of client isolation may be platform dependent, but is known to tiie gate fectory. In some 
embodiments, a hardware-based physical identification metiiod may be used to authenticate tiie cUent For example, 
35 the user may supply a physical identification such as a smart card for identification and authorization. CWher 
mechanisms for authentication may be used in other embodiments. 

Message gates in the distributed computing environment are typically associated witii a single client The 
gate factoiy may determine tiie means of association. The checks performed at message send time may ensure tiiat 
the proper client is using the gate. In one embodiment, gates may be passed in messages, and may be cloned if a new 
40 cMent wishes to use the gate. The cloning process may perform a new set of creation checks, 
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Once a client of a space (the client may be another service) finds the advertisement of a space service, the 
client of the space may run the space service, as it would any other service. Running a space service may involve 
using an authentication mechanism. Running a space service may include, but is not limited to: 

1. The client of the space may first run an authentication sendee that may be specified in the 
service advertisement of the space service to obtain ah authentication credential 

2. The client ofthe space may use the authentication credential, the XML schema of the space 
(firom space's service advertisement), and the URI of the ^ace (from spacers service 
advertisement) to construct a gate for the space. In one embodunent, the client may pass the 
information to a gate fectory to construct the gate. 

3. The client of the space may run the space service by using the gate to send messages to the 
service. 

4. When the space service receives the first message from the client, >vidi the authentication 
credential embedded, the space service may use the same authentication service used by the 
chent to obtain tiie authentication credential to autiienticate the client, thus establishing the 
client's identity. 

5. The space service may then determine the chenf s capabilities (e,g. what the client is 
allowed to do on the space sorice) and bind the capabilities to the authentication credential 

As discussed in the Spaces section, a space's fecilities may include an interrfece for spawning an empty 
space with substantially the same fimctionality (same XML schema) as the space from which it is spawned. The 
spawning faciUty may be usefiil, among other thmgs, for dynamically generating spaces for results. When a 
requestor has spawned a space, only the requestor may be allowed to access the spawned space. For example, the 
spawned space may be for storing results from a service that the client needs to keep secured. This security may be 
ensured by: 

• Creating an initial root authentication credential, and initializing the authentication service ofthe spawned 
space, so that the authentication service only authenticates the root authentication credential, and so that it 
returns no other authentication credentials (no other clients of the spawned space aUowed htitid^^^ 

• Initializdng the security policies of the spawned space so that the root identity associated with the root 
authentication credential has access to all fecilities of the space, including the security administration 
facilities. 

• Returning the root authentication credential and the sendee advertisement of tiie spavraed space to the 
requestor of the spawned space. 

The requestor may build a gate to access the spawned space, since it is returned the authentication 
credential and the service advertisement of tiie spawned space, M one embodunent, only the requestor and clients or 
services tiiat the requestor passes the authentication credential and the spawned spacers service advertisement may 
access tiie spawned space. Such hmiting of access to tiie spawned space may be useful when a client and service are 
using that spawned space to store results, for example, if tiie client and service desire to keep the results private. 

After runmng a service, tiie client may change the authentication policies of the spawned space using a 
security administration space fecility, and otiier clients or seryices may then access the spawned space. In addition, 
the spawned space's service advertisement may be made available to other clients ofthe spawned space (the otiier 
clients may be services) using the discovery protocol or other means. 
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The message transport layer in a distributed computing enviromnent may include mechanisms for 
protecting the security and integrity of communications among clients and services during transport. This security 
may be referred to as 'Svire security" or 'transport security" to distinguish it from the authentication security 
hnplemented by the messaging system including gates. Encryption of messages may be provided at the message 
5 transport layer of the distributed computing envhonment. Services that request an encrypted transport may do so by 
tagging the XML advertisement The gate factory may then create a gate (or gates) that uses a secure message 
transport such as those provided by Bluetooth and HTTPS. 

HTTPS (Secure Hypertext Transfer Protocol) is a Web protocol that encrypts and decrypts user page 
requests as well as the pages that are returned by the Web server. HTTPS may use a multi-bit key size (may vary 
10 from 40 to 128- bit or more) for a stream encryption algorithm (e.g. RC4), to provide an adequate degree of 
encryption for commercial exchange, HTTPS may be iised as a transport in die distributed conq)Uting environment 
Bluetooth is an emerging peer-to-peer wireless communications standard. The Bluetooth key generation 
algorithms may be used in the distributed computing envu-onment Bluetooth may support encryption keys. 
Encryption keys are transport dependent, while chent, service, and combination keys may be transport independent 

15 

' Figure 26a - An authentication service providing an authentication credential to a client 

Figure 26a is a flow diagram illustrating an authentication service providing an authentication credential to 
a client according to one embodiment A client in the distributed computmg environment m^ desire a service to 
perform one or more functions on behalf of the client. In one embodiment, an authentication service may be 
20 provided for use by the client and the service when setting up a secure messaging channel. An authentication 
service may perform functions for the client and/or service including authenticating the client and/or service and 
negotiating the desired level of security and the set of messages that may be passed between the cUent and service. 
The authentication service may be a process that is executing within the distributed computing enviroianent. The 
authentication service may be executmg on the same device as die service and/or the cUent, or alternatively the 
25 authentication service may be executing on a separate device such as an autiientication server. In one embodiment, 
the authentication service may be an fritemet-based service. The authentication service may have its own address, 
for example, a Universal Resource Identifier (URI), through which the client and/or service may communicate with 
die authentication service. In one embodiment, the address of the authentication service may be provided to the 
client m the service advertisement for the service. The client and service sharing an authentication service may help 
30 insure that a secure messaging channel may be established between the client and the service, as any of several 
security and authentication protocols may be used m the messaging channel. 

In one embodiment, a client may present a client identification token or credential to an audientication 
service. The client token or credential may be sufficiently unforgeable to be used as proof of the client's identity. 
Hie autiientication service may then check the client identification token or credential, and issue to the client an 
35 autiientication credential that only the authentication service can create. Hie autiientication credential that is 
returned to the client is then sent in ev^ message by the client to the service. In one embodunent, the client 
message gate is created by a gate fectory, which mcludes the autiientication credential in the message gate, and thus 
the message gate includes the authentication credential in every message tiiat it sends to the service on behalf of the 
client. When receiving a inessage, tiie service may tiien check die authentication credential. Smce only the 
40 autiientication service can create die authentication credential, die service knows that the client did not forge the 
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authentication credential. In one embodiment, the service may pass the authentication credential to the same 
authentication service used by the client to ensure the authentication credential is valid, to verify that the client is an 
authorized client, and to find out the identity of the client 

All services, includmg space services and authentication services, may authenticate their clients. Once a 

5 service authenticates a client, the client may access the service. For example, in the case of a space service, a client 
may then obtain XML advertisements from the space. 

hi one embodiment, a service may have a prearranged credential that all clients of the service are to use. In 
this embodiment, the authentication may provide the prearranged credential to a requesting client. Any client 
presenting the prearranged credential to the service may be approved by the service. 

10 In step 1000, the cHent may request an authentication credential from the authentication service. In one 

embodiment, the cHent may search for and locate a service advertisement for the desired service. In one 
embodiment, the service advertisement may include an advertisement for the authentication service to be used to 
obtain an authentication credential to be used in accessing the service. In one embodiment, the service 
advertisement may include an address such as a URJ for the authentication service. In one embodiment, the client 

15 may send information to the authentication service requesting the authentication credentiaL In one embodiment, the 
cHent may send information to a gate creation process, for example, a gate factory, and the gate creation process 
may access the au&entication service to obtain the authentication credential. 

In step 1002, the authentication service may generate an authentication credential for the client The 
authentication credential may be a data element or data structure that may be embedded in messages in a messaging 

20 system and that may allow receivers of the messages to authenticate the sender of the message, to verify the message 
is from an authorized sender, and to verify that the message is a message the sender is allowed to send to the 
receiver. In one embodiment of a distributed computing environment, an authentication credential may be unique to 
the messaging channel set up between a particular cUent and a particular service. Step 1002 is fiirther illustrated and 
described in Figure 26b. In step 1004 of Figure 26a, the authentication service may return the authentication 

25 credential to the cHent In one embodiment, tiie authentication credential may be returned directly to the client In 
one embodiment, the authentication credential may be returned to a gate creation process, for example, a gate 
fectory, \\Wch may tiien use the authentication credential in generating a gate. 
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Fi gure 26b - An authentication service g , eherating an a uthentication caredential 

Figure 26b is a flow diagram expanding on step 1002 of Figure 26a and illustrating an antlientication 
service generating an authentication credential according to one embodiment In step 1002a, in one embodiment, 
the authentication service may obtain a client token and a service token. In another embodhnent, the authentication 
5 service may obtain only a client token. In one embodiment, the client token may be a unique identifier for the client 
in the distributed computing environment to one embodiment, the service token may be a unique identifier for the 
service in the distributed computing enviromnent For example, the public keys from a public/private key 
encryption mechanism may be used as unique identifiers for the client and the service, to one embodtoient, tha 
client may receive the service token m the service advertisement, and the client may provide the cUent token and the 
10 service token to the authentication service, to another embodiment the client may provide the client token and the 
service advertisement UW to the authentication service, and the authentication service may retrieve the service 
token from the service advertisement 

In step 1002b, the authentication service may verify the client and/or the service, to one embodtoient the 
authentication service may use the client token and the service token obtained in step 1002a to verify the cUent 
15 and/or service, to another embodhnent only a client token was obtained in step 1002a, and thus only the client 
token is used to verify the cheat in step 1002b. to one embodiment the client may have previously registered its 
cUcnt token with the authentication service, and the authentication service may compare the received cUent token to 
the registered client token to verify the cUent as a valid client to one embodiment the client may access the 
authentication service using a chaUenge/response mechanism such as a logon account with password a^^ 

20 be verified as a valid client to one embodiment the service may have deviously registered with the authentication 
service, and may have provided its service token to the authentication service. The authentication service may then 
verify ttiat the client is attempting to access a valid service by comparing the received service token to the previously 
registered service token. Other types of cUent and service authentication may also be used. For example, the client 
may provide a digital signature or digital certificate that the authentication service may use to authenticate flie client 
25 and/or to authenticate the service the client is trymg to access. 

to step 1002c, the authentication service may generate an authentication credential, to one embodhnent 
the authentication credential may mclude an aua.entication token that only the authentication s^^ In 
one embodhnent the authentication service may use the cUent token and the service token in generating the 
authentication credential to another embodtoient tiie authentication service may use just tiie cUent token to 
30 generate the authentication credential, to yet another embodtoient the authentication service may not use an 
obtamed token m the generation of the authentication credential, but may instead use an authentication credential 
generation algoritton to generate a substantially unforgeable authentication credential, to one embodmient the 
authentication service may combme the service token and client token to create a unique authentication credentiaL 
For example, the service token and cUent token may be 64^.it values, and the two tokens may be combmed to 
35 genemte a 128-bit authentication credentiaL Other embodiments may use other methods to generate an 
authentication credential. 
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Bridging Devices to the Distributed Ne twork Environment 

Tliere may be devices, external to the distributed computing enviromnent, which do not support the 
message passing model implemented by tiie distributed computing environment These devices may provide 
services that may be useful to clients in the distributed computing environment. Hie distributed computing 
enviromnent may include a mechanism to bridge such extemal devices to the distributed computing enviromnent so 
that clients in the distributed computing enviromnent may access the services offered on such devices. The 
distributed computing environment may also leverage existing device discovery protocols for discovering such 
external devices for use in the distributed computing environment 

Many technologies define discovery protocols for publishing and monitoring a networkfs device 
composition. These technologies include, but are not limited to: Jini, SLP. Bluetooth, and UPdP. Furthermore, 
many I/O buses such as LonWoiks, USB and 1394 also support dynamic discovery protocols. The distributed 
computing environment may leverage device discovery technologies by mappmg their implementations in an APL 
Leveragmg other device discovery protocols and providing a method to bridge to other discovery protocols may 
allov. the distributed computing enviromnent to discover devices or services aa a wide variety of network and I/O 
buses. Device discovery in the distributed computing environment may thus be appUcable to a wide range of 
devices including smaU devices such as PDAs, even if they do not participate directly in the distributed computing 
enviit»nment Discovery protocols may be defined at flie message leveL 

A bridging mechanism may be provided for "wrapping" one or more specific device discovery protocols, 
such as Bluetooth's, in a messagmg API for the distributed computing enviromnent Wrapping may include flaming 
the device discovery protocol with code and/or data (the API) so that the protocol can be run by cUents and/or 
services in the distributed computing enviromnent that would not otherwise be able to run it When nm, the 
bridging mechanism may allow for a discovery agent that discovers devices by a specific device discovery protocol 
to publish services for those devices in a space in the distributed computing enviromnent The services present an 
XML message schema interface to clients in the distributed network enviromnent, and are capable of operating the 
various devices discovered by the specific device discovery protocol Thus, service advertisements may be 
pubUshed for the services that operate the various devices discovered by the miderlying wrapped device discovery 
protocols. The advertised services thus bridge devices (or services) external to the distiibuted network enviromnent 
to clients on the distributed network enviromnent 

Figure 27 illustrates one embodiment of a distributed computing environment with a space 1200. One or 
more discovery agents 1204 may participate in an external discovery protocol and bridge to the distributed 
computing enviromnent through bridging mechanism 1202. When the wrapped device discovery protocols are run, 
discovery agents 1204 through bridging mechanism 1202 may publish service advertisements 1206a-1206c in spape 
1200. wherein each one of advertisements 1206a.l206c corresponds to a device or service discovered by one of 
discovery protocols 1204 outside the distributed computing environment CUents may then access the external 
35 devices using die service advertisements 1206a-1206c in space 1200 to instantiate services on one of the agents 
1204 that operates the correspondmg external device or service. 

Thus, clients of tbe distributed computing environment may nse discovery agents wrapping device 
discovery protocols to find devices. A service acting as a bridge to these devices may be published in a space and 
advertised, so clients of the distributed computing environment may access the services provided by the external 
40 devices. The advertised service is a service witftin the distributed computing enviromnent that is able to invoke a 
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device outside the distributed computing environment via another protocol or environment, tos bridging the outside 
device/service to the distributed computing environment. A client within the distributed computing environment 
"sees" only the advertised service within the distributed computmg environment and may not even be aware of 4e 
outside device/service. 

5 In one embodiment, the distributed computing environment may provide a version of a space discoveiy 

message protocol, such as the discovery protocol described m the Spaces section, that may be mapped to an 

underlying external device discoveiy protocol, including the wrapped device discoveiy protocols described above. 

The mapped discovery protocol mj^ register itself rar be registered with a space, e.g. a defeuK space, by placing an 

advertisement m that space. For each advertised discoveiy protocol, a subsequent results space to hold the results of 

10 the discoveiy protocol may be provided. 

Figure 28 iUustrates an example of fte space discovery pnitocol m^ped to a Bluetooth discovery servi^ 

mo according to one embodiment The Btaetooth discovery service 1220 may first register 1230 with the 
distributed computing envhonment The Bluetooth discovery service 1220 may be wrapped in a brid^ API, and 
an advertisement 1225 for the discovery service 1220 may be added 1232 m space 1224. A client or service m^ 

15 locate the discovery service advertisement 1225 on space 1224. When the discoveiy service 1220 is executed 
(utilizing the API wrapper as a bridge between the discoveiy protocol 1220 and the distributed computing 
environment 1222), a new space 1226 may be created 1234 to store the results of the discoveiy process. The 
discoveiy service 1220 may store the results (again through the API wrapper) to discoveiy results space 1226 as one 
or more advertisements 1227. Alternatively, results of executing discovery service 1220 may be stored to space 

20 1224 or other pre-existing spaces in the distributed computing environment A simDar method as iUustrated in 
Figure 28 may be used to discover devices and other services using other underlying discoveiy protocols. 

As mentioned above, there may be devices, external to the distributed network envutimnent, which do not 
support the message passmg model implemented by die distributed network environment Tliese devices may have 
cUents that may want to use services provided in die distributed computmg environment The distributed computing 

25 environment may provide a mechanism to bridge the external clients or client devices to the distributed computing 
environment so that the cheats on the external devices may accbss services in the distributed computing 
environment 

Agents may be provided that serve as clients in the distributed computing environment to bridge external 
cUents to die distributed computing environment, allowing the external cUents to access services published m the 

30 distributed computing environment In one embodiment, an agent may ha:ve an XMI^nabled back end capable of 
communicating wifli services in the distributed computing environment usmg die message passing model, and a 
proprietaiy protocol (e,g. a protocol supported by the external device) on the front endto mterfece to the external 
device, and thus to the external cUent Thus, a client external to the distributed computing enviromnent may locate 
and access services in the distributed computing enviromnent through the bridging agent, and m^ send requests to 

35 the services and receive responses from the services, including results data. For example, an external cUent may use 
the bridging agent to run space discoveiy in the distributed computing environment, look up advertised services, and 
invoke services m the distributed computing environment 

m one embodiment, tiie dishibuted computing environment may provide a bridgmg mechanism for 
accessing Jini services from a distributed computing enviromnent client Smce Jini' services miqr require Remote 

40 Method Evocation (RMI). and since clients in tiie distributed computing enviromnent may communicate to services 
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using messages such as XML messages, a protocol bridging mechanism may be provided to enable the access of a 
Jini Service by a distributed computing environment client In one embodiment, a coimector mechanism may be 
defined that enables the dynamic advertisement of Jini services in distributed computmg environment spaces, and 
that also may enable the accessing of a Jini service proxy from clients in the distributed computmg environment In 
one embodunent, there may be Jini services that may not be bridged to the distributed computing environment 

In one embodiment, an agent may be provided as a service m the distributed computing environment that 
bridges the Jini RMI protocol used by Jini services to XML messaging used by distributed computing environment 
clients. When the agent is started, the agent may perform a lookup on the Jmi spaces for Jini services that have a set 
of attributes. For every registered Jini service, the agent may generate an XML advertisement that may correspond 
to the service and may register the advertisemeDt in a space in the distributed computing environment In one 
embodiment, an agent may register for event notification in the Jini Lookup service, and tiius may be informed yvhax 
a new Jini service is registered. When informed of a new Jini service, the agent may perform a lookup in jini spaces 
to locate newly advertised Jini services and to update the distributed computing environment space with new XML 
advertisements for the new services. In one embodiment, when a Jini service is removed, the agent may receive an 
event notift^ing of the removal of the Jini service. The agent may then remove the XML advertisement for the 
service from the space. 

In one embodiment, to invoke a Jini service via an XML advertisement in a distributed computing 
environment space, a client may look up the service advertisement in the space and may send valid messages to the 
agent to access the service. The agent may invoke the proxy service corresponding to the Jini sendee by invoking 
the corresponding method through an RMI call to a service proxy. If the proxy is not instantiated, the agent may 
download the proxy code and instantiate a new instance of tiie proxy object In one environment, eveiy client 
connection may have a different proxy-instance. The incoming message from the client may be converted by the 
agent mto a method caU for tiie proxy. The result from the method call may be returned to the client as an outgoing 
message. 

In one embodim^t, only simple Java types may be used as arguments to an RMI method. If complex Java 
types are reqmred, then one or more data advertisements may be passed as arguments to the call, where the data 
advertisements may indicate the location and access method of data for the complex Java types. In one 
embodiment, the agent may perform initial conversion from XML messages to an RMI method caU mvocation 
dynamically. Since, the agent knows the service interface, it may generate the corresponding set of messages that are 
advertised to the client 

Figure 29 illustrates bridging a client 1250 external to the distributed computing environment to a space 
1254 in the distributed computing environment Bridgmg agent 1252 may serve as the go-between between client 
1250 and space 1254. Bridging agent 1252 may communicate with client 1250 m a communications protocol 
understandable by the cUent 1250. Bridgmg agent 1252 may map the cHent's conamunications protocol into the 
XML messagmg protocol necessary to communicate witti space 1254 perform the fecilities provided by space 1254- 
Bridging agent 1252, at cUent 1250's request, may locate and run services on space 1254. For example, client 1250 
may request a list of aU services of a particular type from space 1254. Bridging agent 1252 may locate service 
advertisements 1256a-c and return the results to client 1250. Alternatively, the results may be posted in a results 
space, and the location of the results may be returned to the cHent 1250. CUent 1250 may then choose to execute 
service advertisement 1256a, and may send a message (in the client 1250's communications protocol) to bridging 
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agent 1252, Bridging agent 1252 may then send the XML request message(s) necessary to execute the service 
represented by service advertisement 1256a, and may return the results of the sendee to client 1250. Methods of 
handling the results of the service other than du-ectly returning the results to the client 1250 may be used as 
described above in the section titled Spaces. Bridging agent 1252 thus may act as a service of the external client 
1250 (via the external client's protocol) and as a client within the distributed computing environment to bridge a 
service withm the distributed computing envkomnent to the external client 

Sometimes, even within the distributed computing environment, cUents and services cannot directly 
communicate with each other, only to a common space. In this case, the space service wiU automatically create a 
service proxy that bridges client to service. The pro^^s main job is to route messages between client and service 
through the space. The service proxy may be created dynamically. The creation mechanism may be dependent 
upon space hnplementation- Refer to Figure 30 for an illustr^on of a proxy mechanism. A client 554 and a service 
556 m^ not be able to communicate directly within tiie distributed computing environment, e.g., because they 
support different transport or network protocols. However, tiiey botfi m^ be able to communicate witii a space 552 
that supports both protocols. The space service may create a proxy 550 to bridge the client 554 to die service 556. 
A common form of pro^o^ is a browser pro^. A browser proxy (most commonly implemented as a servlet) may 
translate conventional Web page requests mto messages. Refer also to the description of space search services (and 
proxies therefore) in the Spaces section herein. 

The distributed computing environment may provide a mechanism for bridging clients in tire distributed 
computing environment to enterprise services. In one embodiment of a distributed computing environment, a 
metirod for bridging clients to enterprise services may include a client withm the distributed computing envhonment, 
a bridge service witiiin the distributed computing environment, and an enterprise service within the enterprise 
environment. The distributed computing environment bridge service serves as a bridge service between the client 
and die enterprise service. An enterprise may be a corporation, small busmess, non-profit institution, government 
entity, or otiier kind of organization. An enterprise may utilize an enterprise computing environment for conducting 
a portion of its business. The enterprise computing environment may mclude various enterprise services. CUents in 
the distributed computing environment may desire to use services in the enterprise computing envhonment An 
enterprise service may be based on a number of architectures, such as three tiered cUent/server architectures. An 
example of an architecture that may be used to implement an enterprise service is Enterprise JavaBeans. Enterprise 
JavaBeans (EJB) is an architecture for setting up program components, written m tiie Java programming language, 
that run in the server parts of a enterprise environment using a client/server model. In object-oriented programming 
and distributed object technology, a con^onent is a reusable program buildmg block that may be combined widi 
other components m tiie same or other computers m a distributed network to form an application. EJB is built on the 
JavaBeans technology for distributing program components (Beans) to cHents in a networic To deploy an EJB Bean 
or component, it must be part of a specific appUcation, which is caDed a container. In Enterprise JavaBeans, there 
are two ^es of beans: session beans and entity beans. An entity bean is described as one tiiat, unlike a session bean, 
has persistence and can retam its origmal behavior or state. Using EJB, programs may be deployed across 
substantially all major operating systems. EJB's program components are generally known as servlets (Uttie server 
programs). The appHcation or container that runs the servlets is sometimes caDed an application server. 

The bridge service interacts with'the cHent via XML message passing to gather mput parameters necessary 
to make requests to the enterprise service outside of the distributed network environment For example, the bridge 
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service may be looked up and instantiated by the cHent just as any other service in Ae distributed computing 
environment The bridge service then may interact with the enterprise service to run the enterprise serv^^ This 
interaction may use an interprocess connnunications architecture that the enterprise service can understand. As an 
example, if an enterprise service is implemented with Enterprise JavaBeans (EJB), a bridge service may 

5 communicate with the enterprise service using EJB. The bridge service may then receive results from the enterprise 
service and may return the results directly to the client (in XML messages) or may place the results in a space in the 
distributed network environment (e.g. a results space). To client, the bridge service ^pears to be the only 
service (the enterprise service is hidden to the client), so the client does not have to support the architecture of the 
enterprise service. Multiple distributed network environment clients may use the same bridge service (each using a 

10 imique gate pair) to interact with the enterprise service. 

The bridge service or otiier agent may publish an advertisement for the bridge service (and thus for the 
enterprise service) in a space in the distributed computing environment For exanq)le, a bridge service or other 
bridge agent may use Java Reflection to examine Beans for services m an enterprise system inq)lemented with EJB, 
and then create service advertisements for bridge services to the Beans and publish those advertisements in spaces in 

15 the distributed computing environment Reflection is a metiiod for Java code to discover information about the 
fields, metiiods and constructors of classes, and to use reflected fields, methods, and constructors to operate on their 
underlying counterparts on objects, within secmity restrictions. The Reflection API accommodates plications that 
need access to eitixer tiie public members of a target object or the members declared by a given class. Once the 
bridge services are advertised, clients may access tiie bridge services (and thus tiie corresponding enterprise 

20 services) snnilarly to any other advertised services in the disbibuted network environment 
architecture of the enterprise service providing the services. 

Client Displays 

There are several methods in which results from a service run by a client may be displayed in a distributed 
25 computing environment Devices that may display results may include, but are not limited to: CRTs on computers; 
LCDs on laptops, notebooks displays, etc; printers; speakers; and any other device capable of displaying results of 
the service m visual, audio, or other perceptible format The methods for displaying results may include, but are not 
limited to: 

• The service may return results to a client directly or by reference, and the cUent may handle the 

30 display of the results. 

• The service may return results to a client directly or by reference, and the client may pass the 
results to a display service directly or by reference, and the display service may display the results. 

• The service may directly handle the displaying of the results. 

• The service may pass the results to a display service directiiy or by reference, and the display 
35 service may display the results. 

In frie last method of displaying results, the client may specify tiie display service. For example, there may 
be a display service on or associated with the device on which the cHent resides tiiat the client wishes to use to 
display flie results of the service. When the cUenf runs the service, the cUent may send a message to the service 
specifying tiie service advertisement of the client's display service. The service may then build a gate that allows it 
40 to send messages to the cUent's display service. Thus, when displaying results, tiie service mvoked by the client 
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becomes a client of the client's display sendee and sends its results (directly or by reference) for display to that 
display service. More detail on the client-service relationship, gates, and messagbg is included in other sections of 
this document 

Conventional application models are typically based on predetermined, largely static user interface and/or 
data characteristics. Changes to conventional appUcations may requke code modification and recompilation. The 
mechanisms described for advertising services and for specifying XML message schemas for communicating with 
services m the distributed computing environment may be used to provide a mechanism for applications (cUents, 
services, etc) to describe dynamic display objects. Using the dynamic display objects, application behavior may be 
altered without having to download new code, lecompOe, or re-link the application. Display schemas may be 
provided for displaying the same results in different fonnats, for extracting portions of the results for display, and 
for displaying the results on different display devices. 

Figure 31 illustrates one embodiment of a client 1300 vwtfa associated display 1302 and display service 
1304 according to one embodiment An advertisement 1306 for display service 1304 may be registered on space 
1308. An advertisement 1312 for service 1310 may be registered on space 1314 by service 1310. Alternatively, 
service advertisement 1312 and display service advertisement 1306 may be registered on the same space. Ghent 
1300 may search for and discover (1320) sendee adverdsement 1312 on space 1314, and may then set up a gate to 
send requests to (and receive results or responses from) service 1310. In one embodiment, the messages may be in 
the form of XML messages specified in an XML schema received as part of advertisement 1312. Client 1300 may 
send one or more messages (1322) to service 1310. The one or more messages may include messages for runnmg 
service 1310 and for instructing service 1310 to send results to display service 1304 for display, and may specify the 
location of display service advertisement 1306. The advertisement location may be specified as aUniform Resource 
Identifier (URI). 

The messages from client 1300 to service 1310 may instruct service 1310 to perform one or more 
operations that produce displayable results. Service 1310 may retrieve display service advertisement 1306 from 
space 1308 based upon the location information received from cUent 1300, The service advertisement may include 
the XML message schema and other information necessary to interface with display service 1304. Service 1310 
may then set up a gate to send requests to (and receive results from) display service 1304. M other embodiments, 
messages from chent 1300 to service 13 10 may include the XML schema and other information needed for service 
1310 to construct a gate to display service 1304, or may include a pre-constracted gate to display service 1304. 

During or after completing, operations requested by client 1300, service 13 10 may send fte results of &e 
operations to display service 1304 in the manner specified by the schema for display service 1304 (e.g. encapsulated 
in XML messages specified in the XML message schema or by reference as parameters for the display service). In 
this regard, service 13 10 may be a cHent of display service 1304. Display service 1304 may then format and display 
the results received from or indicated by service 13 10 on display 1302 for the client 

In some embodiments, service 1310 may post the resulte of operations to a space such as a r^ults space 
(not shown). Service 1310 may then send a message to display service 1304 including a reference to tiie stored 
results of the operations. In one embodiment, the reference may be in the form of a URI. The display service 1304 
may then retrieve the results from the space and display ttie results on display 1302, • 

Conventional application models are typically based on predetermined, largely static user mterface and/or 
data characteristics. Changes to conventional applications may require code modification and recompOation. The 
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mechanisms described for advertising services and for specifying XML message schemas for communicating with 
services in the distributed computing environment may be used to provide a mechanism for applications (clients, 
services, etc) to describe dynamic display objects. Using the dynamic display objects, application behavior may be 
altered without having to download new code, recompile, or re-link Ihe application. 
5 The dynamic display objects may be described in XML schemas. These schemas may be advertised in 

spaces. These schemas may be referred to as display schemas or presentation schemas. An application (or other 
services acting on behalf of the application) may then access the schemas from the service advertisements to display 
data based upon formatting, data type, and other information stored m the schemas. 

The following is an example of a schema contammg dynamic display objects: 

10 

<element name=Mehvery" typeF="Space:shipto" ininOccurs="0" /> 
<type name="TextField"> 
<eleraent nam^" Address" type?="string"/> 
<element nameF="City" type="string"> . 
15 <elementname="State" fype^^string"/^ 



</type> 

20 

The above schema may be changed to the followmg without reqmring an application recompile: 

<element name="delivery" type="Space:shipto" mmOccurs=="0" /> 
<type name=="TextField**> 
25 <element name='TSrame" type=="string"/> 

<element name-* Address" type="string"/> 

<element name="City" type="string"y> 

<elementname="State" typeF="string"/> 



</type?> 

Figures 32A and 32B illustrate examples of using schemas of <^Tiamic display objects according to one 
35 embodiment In Figure 32A, application 1320 (may be a client, a service, or o&er application) has been 
implemented with presentation schema advertisement 1324 stored in space 1326. A presentation schema 
advertisement may include elements describmg the data types, formatting specifications, fonts, locations, colors, and 
any other mformation used for displaying data for the ^plication on displ^ 1322. There may be multiple 
presentation schema advertisements for application 1320. For example, &ere may be one schema for each display 
40 page in a series of display pages (for example, Web pages on a Web site). 
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In one embodiment, application 1320 may invoke a discovery and/or lookup service to locate presentation 
schema advertisements. Hie discovery and/or lookup service may retum an XML docmnent listing one or more 
advertisements, and URIs to each of the schemas describing a particular display format, etc. Application 1320 may 
then select a presentation schema or schemas from the XML document Application 1320 may then parse the 
5 schema, breaking out the elements ofthe schema into user interface components. Tlie components then may be used 
to locate, fonnat, and display results data on the appropriate display. The result data may be from running a service 
or from a results space, for example. Thus, as opposed to havmg a static or predetermined display, the appUcatioi, 
1320 is configured to display i^ults according to a presentation scheraathat may be dynamically changed wfhout 

requiring a rebuild of the application. 
10 Presentation schemas may be provided for displaymg the same results in different fomurt^^ 

portions of the results for display, and for displaymg the lesuhs on different displ^ devices. 

In one embodhnent, one or more presentafion schema advertisements may be stored in one ormoie spa^ 

in a distributed computing environment. As copies of an appUcation are invoked on one or mote devices, each copy 
ofthe application may run a search for services to discover advertisements for the presentation schemas usedby the 
15 applications. TTms. a central, persistent store of the display information may be kept for multiple instances ofthe 
application or for other applications. Tlte display mformadon may be modified in die central location without 
requiring the recompdation and/or reinstallation of flie applications. 

InFigure32B,clientl328maylocateaserviceadvertisementforservicel330onaspace. Wheninvoking 

service 1330, cUent 1328 may pass a location of presentation schema advertisement 1324 on space 1326 to service 
20 1330. Whenservice 1330 is ready to provide results to cHent 1328. it may display the results on display 1322 
(which may be coupled to the device on which cUent 1328 is nmning) using ihe display information from the 
presentation schema provided by presentation schema advertisement 1324. To change the way the results are 
displayed, the XML messages in die presentation schema advertisement 1324 may be modified, or a different 
presentation schema may be selected, without requiring changes at the client 1328 or service 1330. Service 1330 

25 may be a display service. 

A client, application or service my provide a plurality of display schemas for displaying results 

operations provided by one or more services. Alternatively, a display schema may include information for 
displaying a variety of results for one or more clients. Thus, cUent 1328 may use one display schema or a plurality of 
display schemas. Two or more display schemas may be provided for formatting and displaying Ihe same results with 
30 different formats, or on different displays. For example, one display schema for a set of results may be provided for 
displaying results on a display screen, and another for printing the results. Also, copies of the same application. 
cUent or service may run on devices with different display capabilities, so two or more displ^^ 
provided for supporting the display requirements of the different devices. 

35 Strin p Management 

String handling in conventional systems is generally not very efficient, espedaUy for vari*^^ 

andmay be wasteful of memory space, e.g. as the string is copied and/or moved in memory. Hus iaefficiency in 
siring handling may be particularly problematic in smaU memory footprint systems such as embedded systems. Hie 
amount of memory, particularly stack space and space for dynamic allocation, may be limited in smaU footprint 
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systems. Thus, a more efficient method of handling strings in programs executing Avithin small footprint systems 
such as embedded systems is desirable. 

Figure 33A illustrates a typical string representation in the C programming language. In C, a string be 
represented by a character pointer 1450 (stringl) containing a memoo' location (address) of the first character of a 
5 string 1452. Other characten; follow the first character in the string 1452. and are typicaUy stored m consecutive 
addressable byte locations in memory. Characters m C strings are typically 8-bit The characters in C strings may 
be any ASCT character. A C string must be terminated by a NULL character. NULL is platform defined as one of 
the256possMe 8-bit values, but is typically the binary value ObOOOOOOOO. Thestring 1452 occupies 13 bytes(12 
string characters plus the terminating character). 
10 An example of a siring operation in C is the strfenQ fimction, typicaUy provided with standard C horary 

implementations. The strlenQ function takes a string pointer as input and returns the length (in bytes) of the shing. 
not inchKling the terminating character. For example, passing the character pomter 1450 to the strlenQ function 
would return length 12. The strlenQ fimction may be implemented by 'talking" the string untU the teimi^ 
character is located, counting each character. 
15 String copying in C is typically handled by a strcpyQ or a stmcpyQ C h^braiy fimctions, which are 

implemented as: 

char *sti^cpy(char *dest, const char *src); 
char *stmcpy(char *dest, const char *src, size„t n); 
The strcpyO Action copies the string pomted to by the character pointer src (includmg the tenninating character) to 
20 the strmg pointed to by character pointer dest.Tliestrmgsma^ 

large enou^ to receive the copy. 

The stmcpyO Action is similar, except that not more than n bytes of src are copied. Thus, if there is no 
terminatingcharactcramongthefnstnbytesofsrctheresultwiUnotbeterminated. If desired, an mstruction may 
be placed in the code following a StmcpyO to add a termination character to the end ofthedest string. Inthecase 
25 wherethelengthofsrcislessthanthatofn.theremainderofdestwillbepaddedwithnulls. TTie strcpyQ and 
StmcpyQ fimctions retran a pointer to the destination string dest . 

Figure 33B iUusbates an example of the results of the stmcpyQ fimction on string 1452, when stmcpyQ is 
called with the following parameters: 

30 stmcpy(strmg2, stringl+3, 5); 

where string2 is character pointer 1454 pointing to the first byte after the temunating character of string 1452, 
stringl+3 is character pointer 1450 incremented by 3 bytes, and 5 is nmnber 
from the source location stringl+3 to string2. Ato copying, the next character afte^ 
35 strmglmaybesettothetenninatingcharacter(lhecharacterm^havebeeninitiali2ed^^ 

priortothecopy). Thus,thetwostriBgsnowoccupy(13 + 6)=19bytesofmemory. Ifthe strcpyQ fimction was 
appUed with character pointer 1450 as a,e source string, the origiaal strh^ 

occupy,(13*2) = 26bytes. • 
Figure 33C mustrates an efficient method for representing and managing strings in general and in ^ 

systems such as embedded systems in particular. String 1452 is stored in memory as 12 bytes (no terminating 
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character is required). String structure 1460 includes pointers (Address(A) and Address(L)) to the first and last 
characters of string 1452. Using this string stmcture, the string's length may be efficiently computed by subtracting 
the pointer to die first character firom the pointer to the last character. 

Operations such as string copy operations strcpyO and stmcpyO may also be handled more efficiently. 
5 With string structures such as those iUustrated in Figure 33C, a new string structure 1462 may be created, and the 
first and last character pointers rnay be initialized to point to the respec^^ Thus, a 

portion or aU the strmg 1452 does not have to be copied to new storage for the string As strings can be hundreds or 
. even thousands of characters long, the memory saved using the string structures and string methods implemented to 
take advantage ofthem may be considerable. This method of handling copies of portions or all of a string may be 
10 caUed«substringmanagement,"asitdealswiththeefBcienthandmgofporti^ 

Other string functions firom the standard C string Ubraty m^ be replaced with string fimctions takmg 
advantage of the string structure as illustrated in Figure 33C. Examples of other C string functions include, but arc 
not limited to: strstrO>strcatO, mdsprintfO. The string handling structures and methods as described m Figure 33C 
may be used, along with the hierarchical structure of XML documents, to provide more efficient handling of XML 
15 text (such as XML messages) in systemis with small memory footprints such ^ 
a sunple example of an XML schema defining a purchase orden 

<!IXXnOTEpurchase.order SYSTEM "po.dtd"> 

<purchase.order> 
<date>22 May 2000</date> 
20 <billing.address> 

<name>John Smith</name> 
<street>l23 Main</street> 
<city>ABywhere-^city> 
<state>MA<ystate> 
25 <zip>12345-6789</zip> 
<ybilling.address> 
<iteins> 
<itentf> 
<quantity>3</quantity> 
30 <productJiumber>248<;/productnumber> 

<description>Decorative Widget, Red, Large</description> 

<unitcost>19.95<;/unitcost> 
</item> 
<iten^ 

35 <quantity>l</quantity> 

<productnumber> 1 632<yproduct.number> 
<description>Battery, AA, 4-pack<ydescriptioit> 
<unitcos1>4.95</unitcost> 
</item> 

40 <yitems> 

</purchase.order> 

The hierarchical structure of XML documents may allow them to be processed in a recursive feshion widi 
successively smaller portions of the docmnent processed at each level of recinrsion. References to various portions 
45 are recorded and processed recursively. String structures as described in regard to Figure 33C may be used to 
record the various portions. In this manner, the content of specific XML tags (one line in the above example), in 
one embodiment the smallest unit of the XML document processed recursively, may be determined efficiently. 
Documents with repeated tags in the same scope may also be handled efficiently, as ta^ within a given scope may 
be enumerated and processed efBciently. 
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A recursive method for processing aa XML document using string structures similar to tiiose described in 
Figure 33C may accept a string structure representing tlie entire XML document string and pointing to the first byte 
and the last byte in the document string. The method may then locate the next subsection of the document and pass 
a string structure representing the substring of the entu^ document string containing the subsection to a processing 

5 function for the subsection type. The subsection itself may be broken mto another level of subsections represented 
by string structures passed to processing fimctions for tiie subsection type. The method may continue in the 
recursive processing of the XML document subsections until the entire document has been proc^ 

Using the strmg structures with the recursive processing aUows the processing to be done without creating 
copies of the subsections for processing. Copying of subsections may be particularly costly in recursive processing, 

10 because as the recursion goes deeper, more and more copies of the same data are made. Using the string structures, 
only the string structure contaming the pointers to the iBrst and last bytes in the subsection needs to be created and 
passed down to ^e next level Other operations, such as determining the length of a subsection, may be performed 
efiSciently usmg the address information stored in the string structures. Also, by using the string structures, 
tenninating chamcters such as those used to terminate C strings are not necessary, conserving memory m small 

15 footprint devices such as embedded devices. 

XML representation of Objects 

As previously mentioned, Jini RMI may not be practical for some clients, such as thin clients with minunal 
memory footprints and minimal bandwidth. The serialization associated with the Jini RMI is slow, big, requires the 
20 JVM reflection API, and is a Java specific object representatioiL Java deserialization is also slow, big and requires 
a serialized-object parser. Eyen Java based thm clients may not be able to accept huge Java objects (along with 
needed classes) being returned (necessarily) across the network to the cUent, as required in Jini. 

A more scalable distributed computing mechanism may be provided by embodiments of a distributed 
computing environment A distributed computing envhonment may include an API layer for fecilitating distributed 
25 computing. The API layer provides send message and receive message capabilities between clients and services. 
This messaging API may provide an interface for sunple messages in a representation data or metaniat^ 
as in the extensible Mark-up Language (XML). Note ti^ while embodhnents are described herein employing 
XML, other meta-data type languages or foimats may be used in alternate embodiments. In some embodiments, the 
API layer may also provide an interface for messages to communicate between objects or to pass objects, such as 
30 Java objects. Objects accessible through API layer 102 are represented by a representation date format, such as 
XML. Thus, an XML representation of an object may be mampulated, as opposed to the object ibelf 

The API layer may sit on top of a messa^g layer. The messaging layer may be based on a representation 
data format, such as XML. hi one embodiment, XML messages are generated by the messaging layer accordmg to 
calls to the API layer. The messagmg layer may provide defined static messages that may be sent between clients 
35 and sendees. Messaging layer may also provide for dynamically generated messages. In one embodhnent, an 
object, such as a Java object, may be dynamically converted (compiled) mto an XML representation. The object 
may include code and/or data portions. The object's code and/or data portions may be compiled into code and data 
segments identified by XML tags in the XML representation. .The messagmg layer may tiien send the XML object 
representation as a message. Conversely, the messagmg layer may receive an XML representation of an object The. 
40 object may then be reconstituted (decompiled) from that message. The reconstitution may examine the XML 
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representation for tags identifying code and/or data segments of the XML representation, and use information stored 
in the tags to identify and decompile the code and/or data portions of the object. 
Creating and sending an XML representation of an Object 

Figure 34 iUustrates a process of moving Java objects between a cKent 1500 and a service 1502 according 
5 to one embodiment. Service 1502 may be any service supported in the distributed computing environment, 
mcluding space services. CKent 1 500 employs a gate 1504, which may have been created using an XML schema 
received from a service advertisement for service 1502, to commimicate with a corresponding gate 1506 for service 
1502. At some point, client 1500 may need to send Java object 1510 to service 1502. Java object 1510 may 
reference other objects, which may in turn reference other objects, and so otL Java object 1510 and its referenced 
10 objects, the objects they in turn reference, and so on, m^ be referred to as an object graph. 

Java object 1510 may be passed to a Java object compilation process 1512 to be compiled to produce an 
XML representation ofthe object graph. Hie XML representation of the object graph may be passed as an XML 
data stream 15l4 to gate 1504. The XML data stream 1514 may include an XML representation of aU the objects m 
the object graph. In one embodiment, the objects in ftie object graph may be stored recursively in the XML data 
15 stream 1514. 

Gate 1504 may then package the XML data stream 1514 in a message 1516 and send the message 1516 to 
gate 1506 of service 150Z Gate 1506 may extractthe XML data stream 1514 from XML message 1516 and send 
the XML data stream 1514 to an XML data stream decompilation process 1518 to be decompiled to produce flie 
objects) comprising the object graph, mcluding Java object 1510. In one embodiment, the objects in tiie object 
20 graph may be stored recursively in the XML data stream 1514, and thus a recursive decompilation process m^ be 
used. 

When service 1502 needs to send a Java object to cUent 1500. a substantially similar process may be used. 
Java object 1520 may be passed to a Java object compilation process 1512 to be compfled to produce an XML 
representation of the object graph. The XML representation ofthe object graph may be passed as an XML data 
25 stream 1522 to gate 1506. Gate 1506 may then package the XML data stream 1522 in a message 1524 and send the 
message 1524 to gate 1504 of client 1500. Gate 1504 may extract the XML data stream 1522 from XML message 
1524 and send flie XML data sfream 1522 to an XML data stream decompilation process 1518 to be decompiled to 
produce the object(s) comprising the object graph, including Java object 1520. 

In another cmbodunent, the gates m^ be responsible for the compilation and decon^)ilation of Java 
30 objects. In this embodiment, Java object 1510 maybe-passed to gate 1504. Gate 1504 may then pass object 1510 
to a Java object compilation process 1512 to be cona)iled to produce an XML repres«9ilation ofthe object graph in 
an XML data stream 1514. Gate 1504 may then package the XML data stream 1514 in a message 1516 and send 
the message 1516 to gate 1506 of service 1502. Gate 1506 may extract the XML data stream 1514 fiwm XML 
message 1516 and send the XML data stream 1514 to an XML data stream decompilation process 1518 to be 
35 decompUed to produce the object(s) comprising the object graph, mcluding Java object 1510. The process of 
sendmg a Java object from service 1502 to client 1500 inay be substantially similar to fte process of sending an 
object from the client to the service. 

In one embodiment, object compilation process 1512 and object decompilation process 1518 may .both 
exist on the client 1500 and the service 1502, and nay be programmed to perform compflation and decompilation 
40 substantially similarly on the two devices, thus ensuring the object(s) output on one end are substantialty identical to 
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the object(s) input on the other end. In one embodiment, XML schemas mclud% descriptions of Java objects may 
be used on both the client and/or the service in the compilation and decompiladon processes. In one embodiment, 
XML schema(s) to be used in the compilation and decompilation of Java objects may be passed by the service to tbe 

client in the service advertisement. 

XML provides a language- and platform-independent object representation format. Thus, the process as 

illustrated in Figure 34 where an object is compiled into an XML representation of the object and decompiled to 
reproduce the object may not be limited to moving Java objects, but in some embodiments may be applied to 
moving objects of other types between entities in a network. 

JVM compilation/decompilation API 

Figures 35a and 35b are data flow diagrams iUustrating embodiments Miierc a v^ 

includes extensions for compiling objects (e,g. Java Objects) into XML representations of the objects, and for 
decompiling XML representations of (Java) objects into (Java) objects. Tlie JVM may supply an Applications 
Programming Interfece (API) to titie compilation/decompilation extensions. The client 1500 and service 1502 may 
be executing within JVMs. Tlie JVMs may be on the same device or on different devices. 

In both Figure 35a and Figure 35b, the JVM XML compiler/decompila: API 1530 may accept a Java 
object 15 10 as input, and ouQ)ut an XML repr^tation of the object 1510 and aH its referenced obj ects (the object 
graph of object 1510) in an XML data stream 1514. In addition, the JVM XML compiler/decompiler API 1530 
may accept an XML data stream 1522, which includes an XML representation of object 1520 and all its referenced 
objects (the object graph of object 1520), and output Java object 1520 (and all the objects^ i^ 

Figure 35a illustrates one embodiment where, when sending Java object 1510, die cUent calb the JVM 
XML compiler/decompiler API 1530. The client 1510 passes Java object 1510 to the API 1530, which compiles the 
object to produce its XML representation, stores the XML representation in XML data stream 1514, and outputs 
XML data stream 1514. The cUent may then pass XML data stream 1514 to gate 1504. Gate 1504 may tiien 
package the XML data stream 1514 man XML message 1516 and send message 1516 to service 1502. 

Upon receivmg XML message 1524 from service 1502, gate 1522 may extract XML data stream 1522 
from message 1524 and pass data stream 1522 to client 1500, CUent 1500 may then caU the JVM XML 
compiler/decompiler API 1530, passmg API 1530 the XML data stream 1522. The API 1530 may then decompUe 
the XML data stream 1522 to produce Java object 1520 and other objects in its object graph, returning the objects to 
client 1500. 

Figure 35b illustrates another embodiment where, when sending Java object 1510, the SVU XML 
compiler/decompiler API 1530 is called by the gate. The client 1510 passes Java object 1510 to gate 1504. Gate 
1504 then passes object 1510 to API 1530, which compiles die object to produce its XML representation, stores the 
XML representation in XML data stream 1514, and ou^uts XML data stream 1514. Gate 1504 may then padcage 
the XML data stream 1514 m an XML message 1516 and send message 1516 to service 1502. 

Upon receiving XML message 1524 from service 1502, gate 1522 may extract XML data stream 1522 
from message 1524 and pass data stream 1522 to the JVM XML compiler/decompUer API 1530. The API 1530 
may then decompHe the XML data stream 1522 to produce Java object 1520 and other objects in its object graph, 
the gate may then send Java object 1520 and the other objects to client 1500. 
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In one embodiment, the JVM XML compUer and decompfler may be implemented as integrated functions 
of the JVM. In another embodiment, file XML compiler and decompiler may be embodied in API method 
invocations in standard extensions to the JVM; thus, the core JVM does not have to be modified. The JVM may 
supply file JVM XML compUer/decompiler API 1530 to processes (clients and/or services) executing within Ihe 
5 JVM to allow the processes to access the Java object compDation/decompilation functionality provided by the JVM. 
to one embodiment, for a process to utilize the object compUation/decompiktion. the JVM wittiin which the process 
is executing mmt have the JVM XML compUer/decompiler fiinctionality and API 1530. 

Methods using reflection and serialization to transform and send objects are typically implemented in 
applications separate from the JVM. The application must repeatedly access the JVM to pick apart an object one 
10 Md at a time as the transitive closure of the object is dynamically analyzed. Ihis tends to be a slow arid 
cumbeisome process, while also requiring large amounts of apphcation and JVM code. 

Implementing the Java object compilation/decompilation toctionaUty wiftiin the JVM 
because the JVM already understands the concept of, and contents o^ an object graph. Thus, the 
compilation/decompaation flmctions may leverage the knowledge (and reuse code) of the JVM in parsing the object 
15 graph to produce the XML representation, and in parsmg the XML representation to produce the object graph. 
Thus, the compihition/decompflation fimdions may not have to dupUcate toctionahty that is pra^^ 
as &o object sendmg methods using reflection and serialization. This may allow the code footprint of the 
compilation/decompilation functions to be smaUer than that of object sending mefliods using reflection and 
serialization. Also, an object may be complied or decompiled by a single call to the JVM XML 

20 compiler/decompiler API. 

hi addition, integrating the compilation/decompilation of objects with the JVM may aUow the compilation 
and decompilation of objects to be performed faster than methods using reflection and serialization because, in the 
object traversal model hnplemented with reflection and serialization, the code outside the JVM does not know the 
structure or graph of the Java object, and thus must traverse the object graph, pulling it apart, and ultimately must 
25 repeatedly call upon the JVM to do the compilation (and flie reverse process for decompilation). This process may 
be slowed by flie necessity of making repeated calls to the JVM, outside the code. Having the compUation and 
decompilation fimctionaUty integrated with file JVM, as described herem, avoids havmg to make repeated calls from 
code outside ti»e JVM to the JVM. to one embodiment, an objectmay be complied or decompiled by a smgle call to 
the JVM XML compiler/decompiler APL . 
30 to one embodiment, tiie compflation/decompflation fimctionalily may be hnplemented as a service in the 

distributed computing environment The service may publish a service advertisement m a space. A prtjcess in the 
distributed computing enviromnent may use a search or discovery service to locate the compilation/decompilation 
service. The process (a cUent of file service) may fiien nse tiie service by passmg Java objects to be compiled mto 
XMLrepresentationsand/orXMLrepresentationstobe decompiled mto Java objects to fiie service. 
35 Java objects may mclude code (file object's mefirods) and data. An object's code may be non-tr^^ 

code does not change once the object is created. An object's data, however, may be transient Two objects created 
from file same Java class may include identical code, but fiie data in file two objects may be different In one 
embodiment, the compilation fimction mSy compile a Java object's data mto an XML representation of the object, 
but may not mclude fiie object's actual code m fiie XML representation, to one embodunent, infomiation about die 
40 object may be mchided m fiie compiled XML representation to mdicate to fire receiver how to recreate flic code for 
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the object, me XML representation may then be stored in an XML data stream and sent (e.g. in a message) to a 
receiving process (cUent or service). The receiving process may then pass the XML data stream to the 
decompilation function. n,e decompilation fimction may then decompUe the XML data stream to produce the Java 
object including its data. In one embodiment, the code for the object may be reproduced by the decompilation 
Motion using infonnation about the object inchided in the XML representation, as the code for an object may be 
statically defined and the JVM receivmg the object may be able to reproduce the code (if necessary) using its 
knowledge of the object 

In one embodiment, the XML representation of an object produced by the compilation fimction may 
mctade the Java object's data and infonnation about the Java object The infonnation may include class information 
for the Java object An object signature may be included in the infermation and may be used to identify the obj^^ 
class, etc. Tbe decompUation fimction may recreate the code for the Java object usmg the information about the 
Java object and may decompUe the data fiom fte XML data stream into the Java object Thus, a complete object 
including its code and data may be rejproduced on the JVM executing the receiving cUent or service fi:om Ihe 
decompiled data and the infonnation describing the object In one embodiment, the infonnation describmg the 
object may be stored in one or more XML tags, to one embodiment the client or service receiving the XML data 
stream may include an XML schema that describes the object and the XML schema may be used to reconstruct the 
Java object from Ihe decompiled data and bora the infomiation about the Java object The decompilation process 
may proceed recursively through the object graph, reconstmctmg the objects referenced by the object by 
decompiling the referenced objects' data from the XML data stream and recreating the referenced objects' code 
from infonnation about the referenced objects in the XML data stream. 

In one embodiment the XML representation of the object produced by the compilation fimction may 
include the object's data and mfonnation that identifies the code of an object In one embodiment, the infonnation 
identifying the code of the object may be stored m one or more XML tags m the XML data stream. When received, 
the decompilation fimction may recreate the code for the Java object using the infonnation about the code from the 
XML data stream and decompUe the data for the object from the XML data stream. Thus, a complete object 
including its code and data may be reproduced on the JVM executing the receiving client or service from the 
decompiled data and Ihe infonnation descnT5mg the code of the object 

Several scenarios of usmg XML representations of objects to transfer objects between entities (typicaUy 
cheats and services) m a distributed computing environment are mchided for clarification. These scenarios are 

exemplary and are not intended to be limiting. . 

In a first scenario, a service may use the XML compaer/decompfler to compile a Java object into an XML 

representation of the object and send the XML representation to a cUent The client may flie use flie XML 
compaer/decompil^ to decompile the XML representation and perfonn operations on the data within the object. 
andlatermayusetheXML compiler/decompiler to compile the object into an XML representation of the object a^^^ 
return the XML representation of flie object to flie service. 

In a second scenario, a service may use the XML compiler/decompiler to compfle a Java object into an 
XML representation ofthe object and send the XML representation to a client The cUent may flien send the XML 
representation to another service, which may use the XML compiler/decompUer to decompile the XML 
representation to reproduce the object perfomi operations on tiie object at the request of the cKent (possibly 
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modifying the data), use the XML compner/decompiler to recompile the modified object into its XML 
representation, and send the XML representation of the object to the client 

In a third scenario, a service may use the XML compiler/decompiler to compile a Java object into an XM^ 

representation of the object and send the XML representation to an object repository or store space. Hie service 
5 may then send a message to a client informing the client ofthe location ofthe XML representation. The message 

may mclude a Universal Resomce Identifier (URI) for the XML representation. Hie cUent may then retrieve the 
XML representation of the object from the store space, and may use the XML compiler/decompiler to dec^^^ 
representationtoreproducetheobject Altematively, the chent may send the location of tiie XML representation of 
&e object to another service, along xvith a request for operations to be performed on the object IHe ofter service 
10 niaythenretrievetheXMLrepresentationftomthestorespace/usetheXMLcompfler/decompn^^ 
XML representation to reproduce the object, and perform the requested operations on the object 

In a fourth scenario, a process (could be a client or service) may locate an object repository or store space 
in the distributed computing enviromnent by searching for and finding a service advertisement for the store space, 
ne process may, during execution, create or obtam a plurality of Java objects. The process may use tiie XML 
15 compUer/decompaer to compile one or more of the objects mto XML representations of die objects, and may send, 
as a cUent of the store space service, tiie XML representations of tiie objects to the store space to be stored for 
possible later access, or for access by other processes. 

Security issues m tiie Decompflation of XML Representations of Objects 

Spaces.asdescribedherein,mayserveasafflesystemintiiedistributedcomputingenviromnent Security ' 
20 maybeprovidedforfilesinthesysteminlheformofaccessrights. Access rights may be checked each time a file is 

accessed (opened, read, or written to). TTlus. a method for providing file access security in the distributed . 
computing enviromnent may be desirable. This metiiod may also be applied to the XML representations of Java 
objects that may be stored in spaces and tnmsmitted between cUents and services in the distributed computing 
environment 

25 In one embodiment, a user of a chent on a device m tiie distributed computing enviromnent may be 

identified and autiienticated when first accessing tiie client In one embodiment, tiie user may supply a physical 

identification such as a smart card for identification and aufliorization. In anotiier embodiment, a chaUenge- 

response mechanism (such as user ID and password) may be used for identification and authorization. Yet anotiier 

embodiment may use electronic identification such as a digital signatare for identification and authorization. Any 

30 other method of identification and authorization may be used. 

Once identified and authorized, tiie user may then perform various operatiom on tiie cUent. includmg 

accessing one or more services in tiie distributed computing enviromnent During fliese operations, as described 
above. oneormore objectsmaybecreatedOocally)oracquiredfix)melsewhenj(e.g.lh>mserv^ 
objecte may be modified and may be compUed into XML representations ofthe objects and stored locally by tiie 
35 chent or sent to a space service for (transitive or penrfstent) store. Some of ttie objects may be received from 
services (store services or otiier services) in the form of XML representations of flie objects, which may be 
decompiled by tiie XML compiler/deconq>iler to recreate tiie objecfe on tiie cUemt 

In one embodhnen^ during tiie decompilation of tiie XML representation of objects, each XML message 
■ may be checked to verify tiiat tiie user has access rights to tiie object If tiie user does not have tiie proper access 
40 rights, tiie XML compiler/decompiler may not decompile tiie object for tiie user. In one embodiment, a security 
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exception may be ihrown by the XML compfler/decompiler. In one embodiment, the user may be informed of the 

access violation. 

Access right information, such as the creator and access leveb aUowed (creator-only access, read only, 
read/write, delete, copy, etc.) for the object may be embedded in the XML message{s) containing the XML 
1 representation of the object Access authorization may be determined dnring the identification and authorization of 
the user. For example, the object may allow "read only access for most users, and '■readAvrite" access for the 
creator of the object If the user tries to access an object using read/write access rights, and the user did not create 
the object, the decompilation process may detect this as an access violation, and may disallow the access and notify 
the user. 

9 In one embodnnent, when the user is done usmg the client, the user may log off or otherwise signal the user 

is finished with the client (e.g. remove a smart card). Objects created on the client by decompilation may be 
automatically deleted when the client detects lhat the user is finished. This may prohibH fiiture users fiom 
intentionally or accidentaUy accessmg the user's objects. In one embodiment, aU objects aeated by decompilation 
may be deleted upon detecting that the user is finished In another embodiment, a method may be provided to store 

5 at least some of the objects created on the client persistently (e.g. with access rights information), so that the cUent 
may later access the objects, or provide the objects to other users for access. 

In one embodiment, the user may have a "smart card" or other physical device to gain access to die cUent 
n,e user may insert the smart card into flie client device to begm the session. When the client is finished, the client 
may remove the smart card. TTie client may detect the removal of the smart card, and thus detect that the client is 

20 finished, and may then proceed to delete objects created by decompilation of XML representations. 

XML-based object repositories 

hi the distributed computing enviromnent, processes (services and/or clients) may desire transient and/or 
persistent storage of objects such as XML schemas, service advertisements, results generated by services, XML 
25 representations of Java objects and/or objects unplemented in other languages, etc. Existing object storage 
technologies tend to be language and/or operating system specific. Tliese storage systems also tend to be too 
complicated to be used wifli small footprint systons such as embedded systems. 

JavaSpaces in Jini is an existing object repository mechanism. A JavaSpace may be only capable of storing 
Javaobjects andmaybetoo large to be implemented in small devices with Ihnited amounts of memory. Each object 
30 in a JavaSpace may be serialized as previously described, and thus has the same Ihnitations as previously described 

for the reflection and serialization techniques. 

A store mechanism may be provided for the distributed computing environment that may be heterogeneous 

(not language or operatmg system dependent), that may scale from small to large devices, and that may provide 
transient or persistent storage of objects. In one embodiment, the store mechanism in the distributed computing 
35 environment may be implemented as an Memet Web page or set of pages defined in the XML markup language. 
XML provides a language- and platform-independent object representation format enabling Java and non-Java 
software to store and reteieve language-independent objects. Since the store mechanism is on the Web. devices of 
. all types and sizes (small to large) may access the store mechanisms. Web browsers may be used to view the store 
mechanism implemented as Web pages. Web search engines may be used to search for contents in the store 
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mechanism implemented as Web pages. Internet administration mechanisms (existing and Mure) and XML tools 
may be used to administer the XML-based store mechanisms. 

In one embodiment, the store mechanisms may be used to store objects created, represented or 
encapsulated in XML. Examples of objects that may be stored in the store mechanisms may include, but are not 
limited to: XML schemas, XML representations of objects (for example, Java objects compiled into XML 
representations as described above), service advertisements, and service results (data) encapsulated m XML. hi one 
embodiment, to prevent unauthorized access of an XML object, an authorization credential such as a digital 
signature or certificate may be included with the XML obj ect, and a client wishing to access the XML object may be 
required to have the proper authorization credential to access the XML object In one embodiment, the store 
mechanism may be a space as described in the Spaces section herein- 

Store mechanisms may be services in the distributed computing environment A store mechanism 
implemented as a service may be referred to as a "store service". A store service may publish an advertisement m a 
space. The space itself is an example of a store service. Some store services may be transient For example, a 
space service that stores service advertisements may be a transient store. Other store services may be persistent 
For example, a store service that stores results from services may be a persistent store. 

Figure 36 iUustrates a cUent 1604 and a service A 1606 accessing store mechanisms 1600 and 1602 in the 

distributed computmg environment according to one embodiment This ilhistration is intended to be exemplary and 
is not intended to be limiting to the scope of this invention, to one embodiment, store mechanisms 1600 and 1602 
may each be an Intemet Web page or set of Web pages defined in XML and accessible by a Web browser and other 
Internet tools. Store mechanism 1600 is a transient store capable of storing objects inq)lemented using XML. Store 
mechanism 1602 is a pensistent store also capable of storing objects implemented using XML. Service A 1606 may 
publish an XML service advertisement 1608 m transient store 1600. Persistent store may also pubUsh an XML 
service advertisement in transient store 1600 (or on another transient store in the distributed computing 
environment). At some pomt, client 1604 may require fimctionality provided by Service A 1606. Ghent 1604 may 
use a discovery and/or lookup service to locate service advertisement 1608. CUent 1604 may then construct a 
message gate, as described herein, and begin communications with Service A 1606. Client 1604 may send one or 
more XML request messages to Service A 1606. Service A 1606 may perform one or more functions m response to 
the one or more request messages. One or more of the fonctions performed by Service A 1606 may produce results 

to be provided to client 1604. 

For transient results 1610, Service A 1606 may encapsulate theresuhs in an XML advertisement 1612 and 

publish the advertisement 1612 in transient store 1600 (or on another transient store in the distributed computing 
environment). Service A 1606 may then notify client 16Q4 that the results 1610 are stored in advertisement 1612 on 
transientstore 1600, or cUent 1604 may be notified by other mechanisms as described herem. Client 1604maythen 
retrieve transient results 1610 from advertisement 1612. Hie advertisement 1612 may include an XML schema 
describing the formatting, contents, type. etc. of the transient results 1610. The results m^qr be encapsulated in 
XML. For example, XML tags may be used to describe portions of the data: 

<XMLtagl> <datal> 
<XMLtag2>.<data2> 
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For pei^istent results 1618, Service A 1606 may use a service or other mechanism as described herem to 
locate XML service advertiseraent 1616 for persistent store 1602, and &us locate persistent store 1602 for storing 
persistent results. Alternatively, client 1604 may have previously located persistent store 1602 by locating its 
service advertisement 1616, and then may send a Universal Resource Identifier (URI) for a storage location for 
persistent results 1618 to Service A in an XML message. In one embodiment, persistent results 1618 may be stored 
in an Intemet Web page or set of Web pages defined in XML and accessible by a Web browser. Service A 1606 
may then store persistent results 1618 m persistent store 1602. Service A 1606 may then publish an XML 
advertisement 1616 for the persistent results 1618 m transient store 1600 (or on another transient store in tiie 
distributed computing enviroament) and return the location of &e advertisement 1616 to client 1604. The 
advertisement 1616 may include an XML schema describmg the fonnatting, contents, type, etc. of the persistent 
results 1618, The results may be encapsulated in XML as previously described. The advertisement m^ also 
include the UiU of the persistent results 1618. The cHent 1604 may then retrieve the advertisement 1616 and use it 
to locate and retrieve persistent results 1618. Alternatively, Service A 1606 may not publish an advertisement for 
persistent results 1618, but mstead may return a URI for tiie persistent results 1618 to client 1604 so client 1604 
may access the results without looking up an advertisement Note m some embodiments, the various advertisements 
shown in transient store 1600 may each be stored in different transient stores or spaces^ 

Thus, stoit mechanisms may be implemented as XML-based Intemet Web pages in fee distributed 
computing envhonment. These store mechanisms may be implemented on a variety of devices in the environment, 
and may provide service advertisements to aUow cHents (which may be other services) to locate and use the store 
) mechanisms. Existing and future Web and XML tools may be used to manage the store mechanisms. The store 
mechanisms may store objects of various types unplemented or encapsulated in XML. Clients on devices of 
substantially any size, fi-om small footprint devices to supercomputers, may access the store mechanisms to store and 
retrieve the various objects on the Intemet The chents may be Java or non-Java ^plications, as XML provides a 
language-independent storage format The transient or persistent object repositories may provide for a file system in 
25 the distributed computing environment and may include access checks and other security mechanism as described 
herein. 

Dynamically Convertmg a Java Object into an XML Document 

hi one embodiment, the distributed computing environment may provide a mechanism to convert and 
represent an object class instance into an XML document U order to send representation of a class mstance to 

JO another service, tiie object may be converted and represented as an XML document In one embodhnent, when 
receiving an XML document, a program may instantiate a class mstance corresponding to the object represented by 
the document In one embodiment, the objects may be Java objects, and tiie progr^n may be a Java program. 

In one embodiment, an intermediary format may be used to represent an XML document and may be 
dynamically processed to generate a class instance tiiat represents the XN^ 

35 instance variables and "set and ger methods to access tiie instance vari^^^^ 

be defined as a set of tags, witii one tag for each instance variable. When tiie document is parsed, a hashable 
representation may be constructed where the hash key may mclude tiie mstance variable name and tiie vahie may 
include die mstance variable value. If tiiere are multiple occurrences of a complex instance variable, an enmneration 
value may be stored m a hash table. Li one embodiment, tiie process may be limited to only one level of complex 

40 types for tiie mstance variables, and tiie elements may.be homogeneous. 
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In one embodiment, a protected instance variable may be added to the class definition that may include the 
name of the corresponding class. The XML document representation may use the class name as the document type. 
Having the class name embedded in the document may allow dynamic instantiation of the right class instance when 
the object is reconstructed. 

5 In one embodiment, upon receiving a document, a class instance generator method may be used to extract 

the class type and to parse the document to generate the mtennediaiy hash table representation. The generator 

method may mstantiate a new class mstance and may use the set methods to initialize the instance object from the 

hash table values. In one embodmient, since the class type is defmed and the hash table is generic, Ms process may 

be performed for any class that matches the above class definition. 
10 In one embodiment, the reverse pn)cess may also be performed where a class instance may be processed 

into the intermediary hash table representation and a generator method may be used to produce an XML document 

from the hash table representation. This process may also be made generic so that it may be performed for any XML 

document that matches the above specification. 

This method is not intended to be fimited to Java Class objects, and may be ^plied to other computer- 
15 based objects, including class object instances of other programming languages. In addition, the method is not 

mtended to be limited .to XML representations of object instances; other representation formats includmg other data 

representation languages (such as HTML) may be substituted for XML. 



XML-Based Process Migration 
20 The distributed computing environment may enable the distribution and management of distributed 

appUcations. For example, the distributed computing environment may include mobile cUents that are dockable 
with stations that provide monitors, printers, keyboards, and various other input/ou^ut devices that are typicaUy not 
provided on mobile devices such as PDAs, cell phones, etc. These mobile cUents may run one or more applications, 
and may migrate from one station to another m the distributed computing environment Thus, one embodunent of 
25 the distributed computmg environment may provide a method for migrating an executing application (process) with 
its entire current state from a mobile cUent on one node to the same mobile client or another mobile cUent at anoflier 
node within the distributed computing environment. 

In one embodiment, an XML representation of tiie state of a process executing on a cUent or service may be 
created. In one embodiment, the XML representation of the state of the process may include a computation s^^^ 
30 the device and/or vktual machme on which the process is executing, wherein tiie computation state of the device 
and/or virtual machme comprises information about the execution state of tiie process on the device and/or virtual 
machine. A process state may mclude, but is not limited to: threads, all objects referenced by the threads, transient 
variables created during the execution of the process, objects and then: data, etc. In one embodiment, data 
describing one or more leases representing grants of access to external services, obtained from spaces by the 
35 process, wheremtiie one or more extenial services are external to die device and/or vi^^ 

process is executing, may also be represented in XML and stored with the process state. Leases are described in 
more detail in the Leases section of this document 

Using XML and the messaging system as described herein, an XML representation of the state of a process 
may be moved from node to node witihin the distributed computing envkonment, e.g. from node to node on the 
40 Internet The XML representation oftiie state of a process may ako be stored as an XML object in an XNG-b^^ 
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store mechanism as described above, and later retrieved from the store mechanism to resmne the process execution 
on the same node or on a different node in the distributed computiiig environinent In one embodiment, the XML 
object compilation/decompilation process as described herein may be used m creating (compiling) aa XML 
representation of the state of a process and in regenerating the state of the process by decompiling the XML 

5 representation of the state of the process. 

Using this mechanism, an XML representation of the state of a process may be stored in an XML-based 

store mechanism, such as a space, from an initial node. Subsequently, anothernode may locate the stored state of 
the process, download the state of the process, and resume the process from the downloaded stored state at the point 
at which it was executing when the state was stored. Since the process state is stored in an XML format, the tools 
10 and search feciUties described herem to store, locate and retrieve XML objects in XML-based store mechanisms 
may be used to enable the migration of the process. An advertisement of the stored XML representation of the state 
of the process may be published to aUow a client resumic® the process execution on the same node or another node 

to locate and access the stored sate. 

Ibe XML representation of the state of a process m^ be stored to an XML-based persistent store 
15 mechanism, and thus may provide a persistent snapshot of the process. Hus may be used as a method to resume 
process execution on a node after the interruption of the process on the node, for example, due to the mtentional or 
umntentional shutdown of the node. An advertisement of the stored state of the process may be published to allow 
cheats to locate the stored state in the distributed computmg environment In one embodiment, to prevent 
unauthorized access of an XML representation of the stored state of a process, an authorization credential such as a 
20 digital signature or certificate nmy be included with the stored state, and a cUent wishing to 

the stored state may be required to have the proper authoriKation credential to access the stored state. 

Figure 37 iUustrates process migration using an XML representation of the state of a process accordmg to 
one embodiment Process A 1636a may be executing on node 1630. Process A 1636a may be a chent or service. 
At some point during the execution of Process A 1636a, the state of execution of Process A 1636a maybe captured 
25 and stored in an XML-encapsulated state of Process A 1638. TheexecutionofProcess A 1636a on node 1630 may 
then be stopped. Later, node 1632 may locate the XM^encapsulated state of Process A 1638 and use it to resmne 
Process A 1636b on the node 1632. Resuming Process A may include using flie stored state 1638 to resume thread 
execution, recalculate transient variables, re-establish leased resources, and perform any other fimctions necessary to 
resume execution as recorded m the stoned XML state of the process 1638. 
30 The following is an example of usmg XML-based process migration in the distributed computing 

enviiomnent, and is not intended to be limiting. A mobile cUent device may be comiected to node 1630 and 
executing Process A 1636a. The user of the mobfle client device may desire to stop execution of Process A 1636a 
on node 1630, and to resmne execution at a later time at another (or the same) node. In one embodiment, the user 
may be prompted with a queiy to dcteimine if the user wishes to store the state of Process A 1636a and resume 
35 execution later. If the user repUes in the aflSmiative. fte XML^capsulated state of the process may be captured 
and stored in persistent store 1634. Later, the user may comiectthe mobUe computing device at node 1632. to one 
embodiment, the user may then execute process 1636b and select a "Resume from Stored State" option. The node 
■ 1632 may then search for and locate the XML-encapsulated state of Process A 1638, download it, and use it to 
resmne Process A 1636b. Alternatively, the process may itself know that it was "suspended" on anolher node, and 
40 may resume from the stored state without user input 
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A pplications 

Technologies exist that allow a user to access network data from remote locations, making the remote data 
appear as local data to the user, provided the user has access to a browser. However, such technologies do not 
provide an automatic mfrastructure to query networks near a client device's location. A mechanism for discovering 
information about networks and services near a client device may be desfcable. For example, such a mechanism 
may be used to locate infonnation about restaurants, weather, maps, traffic, movie information, etc within a certain 
distance (radius) of the cUent device, and to display desired mformation on the client device. An example of using 
this mechanism may be a cell phone that can be used to automatically locate services in a local enviromnent, for 
example, in a movie theater to display the titles and show times of current features in the movie theater or in a 
restaurant to view menu selections and prices. In the distributed computihg environment as described herein, such a 
mechanism may be used to discover spaces including local information and/or services proxhnate to flie client 
device. The mechanism may also be applied in other distributed computing environments, for example, the Jmi 
system from Sun Microsystems, Inc. 
15 In one embodiment, a mobile client device may include Global Positioning System (GPS) capabiUty and 

wireless connection technology. Local distributed computing netwoite may be provided. For example, a city may 
provide a citywide distributed computing environment Another example may be a shopping mall wifli a local 
distributed computing environment A local distributed computing network may include a discovery mechanism to 
allow client devices to connect to the distributed computing envkonment and to discover services and data in the 
local enviromnent For example, one or more devices m the enviromnent may include wireless connection 
technology to aUow mobile client devices to connect to the network and to access the discovery mechanism via the 
XML messaging system as described previously. A local distributed computing environment may include one or 
more spaces with advertisements for services and/or data to be made available to mobile clients. For example, a 
citywide distributed computing environment may include spaces that represent entities such as malls, movie theaters, 
25 local news, local weather, traffic, etc. A space may include individual service and/or data advertisements for 
accessing services of and mformation about the entity the space represents. The discovery mechanism may include 
a GPS location or locations of the local distributed computing enviromnent, entities represented by space services 
withiri the envffonment. and/or the various services advertised in ttie spaces m the envfronment 

In one embodiment, wired connections may be provided to a local distributed con^utmg network, to this 
enviromnent, a user with a mobUe cUent device may "plug in" directly to the network using a wired comiectioa 
"docking station". Examples of wired connections inctode. but are not limited to: Universal Serial Bus (USB), 
FireWire, and twisted-pafr Memet In one embodiment, a docking station may also provide input/ou^.ut 
capabilities such as akeyboard, mouse, and display for the mobile cMent device, hi this embodhnent, the location of 
the mobile client device may be provided to the lookiq) or discovery mechanism by doddng station. 

In one embodiment, a mobfle client device may connect to a distributed computing network. As the user of 
the mobUe client device navigates vrithm wireless commmucations range of the distributed computing network, the 
mobile cUent device may constantly, or at various intmak, provide a location vector as i^^^ 
discovery mechanism. The mobile cUent device may obtain the location vector from a GPS system built into or 
associated with the mobile client In one embodiment, the cUent may send its location information (e.g. via XML 
40 messaging) to a local service discovery mechanism, such as one of the space location mechanisms descriT)ed herein. 
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For example, the cUent may run the space discovery protocol specifying discovery for spaces offering services 
within acertainrangeofthe client's location, orfhe cUentmay instantiateaspacesearch serviM 

advertismg services provided for the client's vicinity. 

As the mobile client device moves into a specified range of a space within the distributed computing 
5 environment, the services and/or data stored in the space may be made available to the mobile client device. In 
embodiments where the client device regularly provides its location to a discovery mechanism, local services and/or 
data may automaticaUy be made available to the cKent's user. In one embodiment, the user of the mobile cUent 
device may determine the specified range of a space. For example, the user may choose to display all restaurants 
within one mfle of a current location. Alternatively, the range may be specified in the configuration of the local 
10 distributed computing netwodc For example, a citywide distributed computing network may be configured to 
provide its services to all users within three miles of the city limits. In one embodiment, visual indicators, for 
example icons, representing the various services and/or data olfeed by the space may be displayed on the mobile 
client device. The client may then access one or more of the displayed services and/or data. In one embodiment, 
mfonnation ftom two or more spaces may be displayed simultaneously on the mobile cUent device. In one 
15 embodiment, the user may select what services and/or data are to be detected. For example, in a shopping mall, a 
user with a mobile cUent device may choose to displE^ aU shoe stores in the malL 

In one embodiment, executable code and/or data used in fte execution of the code may be downloaded to 

the mobile client device to allow the user to execute an application provided by a service in the space. For example, 
moviegoers with mobUe client devices m^ download interactive movie reviews from services in a space for the 
20 movie theater, and may thus perform real-time feedback about the movie they are watching. In one embodiment, an 
XML object compilation/decompilation mechanism as described elsewhere herein may be used to compile the code 
and/or data to produce XML representations of the code and/or data, and to decompile the XML representations to 
reproduce the code and/or data on the mobile client device. In one embodiment, an executable version of a process 
may previously exist on the mohUe client device, and a stored state of the process may be downloaded to the mobile 

25 client device to aUow the user to execute the process using the stored state. In one embodhnent. an executable 
version of a process may previously exist on the mobile client device, and data for the process maybe downloaded 
to die mobile cUent device. For example, data may be downloaded for viewing with a viewer program on die mobile 
client device. In one embodiment, an executable version of a process, including the code and data for executing the 
process, may be downloaded for execution on the mobile client device. In one embodiment, the service may execute 

30 the appUcation remotely on behalf of the mobUe cUent device, and the service and cUent may pass to each other 
XML messages including data and optionally XML schemas describing the data. In one embodiment, some code 
may be executed on the service and some on the client For example, the service may execute code to perform 
operations on a set of data such as nmnerical calculations. Tte mobile cUent device may execute code that may 
display portions of the (kta passed to the client from the service in XML messages and allow the user of the mobile 

35 cHent device to enter and/or select data and send the data to the service for perfimning one or more operations on 
the data. 

hi one embodiment, a mobile client device may be comiected to two or more services in the distributed 
computing network simultaneously. Hie services may be used independently or in conjunction for perfoimmg a 
series of tasks. For example, one service may be used by a remote cUent device to locate and/or perform operations 
40 on a set ofdata, and a second service may be used to print the set of data. 
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Figure 38 illustrates a mobile client device accessing spaces in a local distributed computing networic, 
according to one embodiment. A user of GPS-enabled mobUe computing device 1700 may move into pro^^^ 

local distributed computing environment The mobile cUent device 1700 may provide its location provided by GPS 
1702 to one or more discoveor mechanisms 1706 m the local distributed computing network. The discovery 
5 mechanism 1706 may use the provided GPS location of the mobfle cUent device and prcdetennined locations of 
spaces within the environment to determine when the user moves yn&m a specified range of one or more spaces or a 
vicinity served by one or more spaces within the environment For eiample. discovery mechanism 1706 may 
determine that mobile client device 1700 has moved within range of space 1704. Discovery mechanism 1706 may 
then provide one or more advertisements 1710 from space 1704 to the mobile client device 1700. Alternatively. 
10 discovery mechanism 1706 may provide a Univeisal Resource Identifier (URI) for space 1704. or for one or more 
advertisements in space 1704, to mobUe client device 1700. Icons representing the various services advertised by 
service advertisements 1708 and/or data represented by content advertisements 1710 m^ then be displayed on 
mobUe client device 1700. Tlie user may then select one or more of the advertised services and/or data for 
execution and/or display ou the mobile cUent device. The mobile computing device 1700 may establish a wireless 
15 comiection with the device offering the service and communicate with the device to execute the service using the 
XML-based messaging system as previously described herein. Alternatively, the user of the mobUe computing 
device 1700 may connect the device at a docking station. He location of the dockmg station may have been 
discovered by the user using the lookup or discovery mechanism 1706. and spaces contaming advertisements for the 
docking stations to discover the location and availability of docking stations within a specified range of the user. 
20 Discovery mechanism 1706 may also detect when mobfle cUent device 1700 moves into a selected range of 

space 1714. The various service advertisements 1718 and content advertisements 1720 may then be made avaflable 
to the user of the mobile cUent device 1700. When the mobfle client device moves out of Ihe specified range of one 
of the spaces, the advertisements offered by that space may be removed from the mobUe client device 1700's 
display. 

25 In one embodiment, advertisements on a space may mclude location mfoimation for the services or data 

that they provide. Thus, discovery mechanism 1706 may determme when mobfle client device 1700 moves withm a 
specified range of a particular service advertised on space 1718. and may provide (or remove) the service 
advertisement based upon the location of the mobfle cUent device 1700. 

Computing devices are shrinkmg while at the same time gaming power and limctionality. Ston^e devices, 

30 CPUs. RAM. I/O ASICS, power supplies, etc. have been reduced in size to where smaU, mobfle cHent devices may 
include much of the fimctionality of a fiJl-sized personal computer. However, some components of a computer 
system are not easfly shrinkable because of the human factor and other factors. TTiese components^ i^^^^ 
not limited to: keyboards, monitors, scanners, and printen. The limits on reducm^ 
may prevent mobfle client devices from truly assuming the role of personal computers. 

35 In one embodiment, dockmg stations may be provided that allow users with mobfle client devices to 

comiect to and use components (bat are not available on the mobfle client device because of human or other fectors. 
For example, docking stations may bo provided in public places such as airports or libraries. Tlie dockmg stations 
may provide monitors, keyboards, printers or other devices for users with mobile client devices. In one 
embodiment, the docking stations may not fiiUy fimction without help from a real computing device such as a mobfle 
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client device connected by a user. The docking station may provide services such as various input/output functions 
to the client using the computing power of the mobile client device. 

A docking station may provide one or more connection options to a mobile client device. The connection 
options may include wireless connections and wired connections. Examples of wireless connections include, but are 
not limited to: infrared such as IrDA and wireless network connections similar to those provided by a network 
interface card (NIC) in a notebook computer. Examples of wired connections include, but are not limited to: USB, 
FireWire, and twisted-pair Ethernet 

A mobile cUent device may discover the location of docking stations using a method substantially similar to 
that described above for mobile cUent devices. The location of one or more docking stations in a local distributed 
computing network may be discovered using a discovery mechanism to discover spaces with advertisements for 
docking stations. The mobile client device may provide a location to the discovery mechanism. In one 
embodiment, the discovery mechanism or a lookup mechanism may return &e location of one or more docking 
stations closest to the location of the mobile client device. Alternatively, the discovery mechanism or lookiq) 
mechanism may return a IIRI of the space containing the advertisements for the docking stations, and the mobile 
chent device may then coimect with the space to provide the location of the one or more docking stations near the 
device. In one embodiment, the mobile client device may supply information to the lookup or discovay mechanism 
to specify requirements such as monitor resolution, screen size, gK^hics capabilities, avmlable devices such as 
printers and scanners, etc. In one embodiment, information about the one or more docking stations mery be supplied 
to the user on the mobile client device including availability (is another user using the docking station), components 
and capabilities of tire various docking stations. 

When a user approaches a docking station, a claiming protocol may be initiated. When the docking station 
accepts the claim, secure input and output connections may be established between the mobile client device and the 
dockmg station. Alternatively, the user may select the docking station from one or more docking stations discovered 
using the lookup or discovery mechanism displayed on the mobile cUent device. When the user selects the docking 
station, the claiming protocol may be initiated to give the user secure, exclusive cormection to the docking station 
for the duration of the claim. A docking station release method may also be provided to allow the user to terminate 
the session on the docking station and release the docking station for use by other users. In one embodiment, the 
claimmg protocol may be a lease on the dockmg station service as described previously herein. 

Figure 39a illustrates a user of a mobile device discovering the location of docking stations according to 
one embodiment. Mobile client device 1750 may connect vwth discovery mechanism 1756. Mobile client device 
1750 may provide a location obtained using GPS 1752 to discovery mechanism 1756. Mobile client device 1750 
inay also provide docking station requirements to discovery mechanism 1756. Discovery mechanism 1756 may^ 
search one or more spaces 1754 for advertisements for docking stations 1758 that meet the requirements of mobile 
client device 1750. In one embodiment, a lookup or discovery mechanism may locate one or more docldng stations 
within a specified range of mobile device 1750 by comparing location information stored in advertisements 1758 
with the supplied location of mobile device 1750. Discovery mechanism 1756 may then pro\ide the location of one 
or more dockmg stations within a specified range of mobile client device 1750. Attematively, discovery mechanism 
1756 may locate a nearest docking station to mobile client device 1750 and provide the location to mobUe chent 
device 1750. 
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Figure 39b illustrates a mobile client device 1750 connecting to a docking station 1760, according to one 
embodiment In one embodiment, the user may move mobile client device 1750 into wireless range of docking 
station 1760 and make a wireless connection to the docking station 1760. In another embodiment, the user may 
establish a wired connection to docking station 1760 by connecting one or more cables between docking station 
1760 and mobile client device 1750. In one embodiment, the user of the mobile client device 1750 may establish a 
claim to the docking station 1760. The claim may establish secure, exclusive rights to the docking station for the 
duration of the connection. In one embodiment, the cldm mechanism may be a lease mechanism for a resource (the 
docking station) as described previously herein. In one embodiment, a user may be billed for use of the docking 
station. For example, the user may supply a credit card number as part of the process of clahnmg a docking station. 
Refer to the description of bill gates in the Mess^e Gates section herem. Once connected, the user may use the 
various fecihties provided by tiie docking station 1760 such as keyboard, monitor, printer, etc. Docking station 
1760 may also include a connection to a local distributed computing network and thus may provide the user of the 
mobile client device 1750 connected to the dockmg station 1760 with discovery services for locating service and 
content advertisements on other devices within the network, allowmg the user to locate and use various services and 
content m the distributed computing environment as described previously herem. 

When finished, the user may disconnect the mobile client device 1750 fiom the docking station 1760. In 
one embodiment, a docking station release mechanism may automatically be initiated when the mobile client device 
1750 is disconnected from the docking station 1750, The release mechanism may clear any claim on the docking 
station 1760 established by the user of the mobile client device 1750. In one embodiment, the release mechanism 
may notify the discovery mechanism 1756 and/or dockmg station advertisement 1758 that the dockmg station is 
available. 

In one embodiment, a user may connect a mobile client device to a docking station without using the 
discovery mechanism. For example, a user m an auport may visuaUy detect a dockiug station and connect a mobile 
client device to it. Anotiier example may be a library providing a docking station room with a plurali^ of docking 
stations for use, where users may access any of the docking stations that are available. 

Small Footprint and/or Embedded Devices 

Simple embedded or small foo^rint devices may have lunited amounts of memory for storing and 
executing program instructions. A sunple embedded device may need to understand a lunited set of control inputs 
for mitiating functionality of the device and outputs for reporting the status of the device. An example of a shnple 
embedded device is a "smart*' switch (such as a light switch) with embedded circuity for controlling the switch and 
thus the device controlled by the svntch. The smart switch may only need to understand two control requests 
(change the state of the device, request the state of the device) and to send one status message (the state of the 
device), the smart switch may manage the device to which it is connected by receiving its control requests from 
one or more control systems and reporting status messages to the one or more control systems. 

In one embodiment, the distributed computing environment may provide a framework (protocol) for 
including small devices that may not have the resource footprint (such as memory) necessary to implement the frill 
protocol of the distributed computing envfronment In one embodiment, an agent may be provided as a bridge 
between the small device-capable protocol and the frill protocol Hie agent may perform the frill protocol discovery 
for the small device, so the device may not be required to nnplement the fuO discovery protocol and service 
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activation. In one embodiment, the small device may only need to send service-specific messages. In one 
embodiment, these messages may be precooked on the small device, so the small device may only have to send 
messages that are part of the service activation to the agent TTie agent may perfoim the service activation via the &11 
protocol to the service and forward incoming message fi«m the device to the service, and/or may forward repUes 
from the service to the cUent Thus, the agent may act as a service comiector for the smaU cUent. 

In one embodiment of the distributed computing enviromnent, an embedded device may be configmed to 
receive a specific set of control requests in the form of XML messages and to send a specific set of XML messages 
to make requests, report status, etc. In one embodiment, a control system may be configured to manage a variety of 
devices by sending XlVfL request messages specific to each device or category of device that it controls and by 
receiving XML messages from the devices. In one embodiment, one or more XML schemas may be used to define 
an embedded device's specific set of XML messages; the schema may be used by the embedded device and/or the 
control system in sending and receiving XML messages. 

An embedded device may include a "thm" implementation of the XML messaging system as previously 
described herein that supports the specific set of messages for controlling and monitormg the shnple embedded 
device. The implementation of the XML messaging system may be tailored for use with small footprint, simple 
embedded devices, and thus may fit in the limited memory of the small footprint devices. In one embodiment, the 
XML messaging system may be implemented in a small footprint with a virtual machine targeted at small footprint 
embedded devices (e.g. KVM). A networking stack (to support the transport protocol for commmucations with one 
or more control systems) may be associated with the virtual machine and the XML messaging layer may "sit on top" 
of the networking stack It is noted that this implementation of the messaging system may be used m other devices 
than small footprmt or embedded devices. 

hi one embodiment, static or pre-generated messages may be used for requests fiom control systems to 
embedded devices. The static messages may be precompiled and stored in the embedded devices. An mcoming 
message may be compared with the stored static messages to find a match for the message and thus to perform the 
fimction requested by the message, thus reducing or elimimdng the need for code to parse incoming messages. 
Outgoing messages may be read directly from the stored static messages, thus reducing or eliminating the need to 
dynamicaDy compile outgoing messages. Thus, static messages may be used to reduce the code footprint of the 
messagmg layer in embedded systems. For example, static Java objects (Java op codes) maybe used for request and 
Status messages. 

Figure 40a Ulustrates an embodiment of embedded devices 1 804a and 1 804b controUed by a control system 
1800. according to one embodhnent Control system 1800 may be networked witii the devices 1804a and 1804b it 
controls in any of a variety of ways. The netwoik 1810 may be wed (Ethernet, coaxial, twisted pair, power grid. 
etc.)and/orwiieless(IrDA.micrt,wave.etc.). In one embodiment, embedded devices 1804a and 1804b may include 
a thin implementation of the XML messaging system for communicating vrith contirol system 1800 over network 
1810. Control system 1800 may have an implementation of the XML messaging system for sending requests to and 
receiving responses from embedded devices i804a and 1804b. In one embodiment, control system 1800 may 
include software and hardware configured to present an interfece to allow a user to display the status of and 
remotely control the embedded devices 1804a and 1804b. to one embodiment, control system 1800 may include 
software and/or hardware for automatic control of embedded devices 1804a and 1804b. 
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In one embodiment, embedded devices 1804a and 1804b may be part of anoHier environment. The 
devices may not support the message passing model implemented by the distributed network environment For 
example, the devices may be nodes in a networked automation and control system such as a LonWorks network. 
Control system 1800 may mclude a control system hardware and/or software for controlling devices in the other 
5 environment Control system 1800 may serve as a bridge between the distributed computing environment and &e 
other environment The distributed computmg envkonment may also provide a method or methods to wap existing 
device discovery protocols for discovering fee devices for access from the distributed network environment 
Bridging and wrapping protocols are fiirther described herein in the Bri 

Control system 1800 may be connected remotely or locally to one or more other systems in the distributed 
10 computing environment Figure 40a shows control system 1800 connected to client 1806 via fee Internet 1802. 
Client 1806 may induectly request fee status ot and send control requests to, embedded devices 1804a and 1804b 
through control s>^tem 1800. Thus, control system 1800 serve as a proxy or bridge for embedded devices 
1804a and 1804b. See fee Bridgmg section herem. To enable sophisticated communicaticm between fee client 1806 
and fee control system 1800, fee cHent and fee control system may have different unplementations of fee XML 
15 messa^g system fean fee fein in^lementation on fee embedded devices 1804a and 1804b. In one embodiment, 
cHent 1806 may include software and hardware configured to present an interfece to aUow a user of client 1806 to 
display fee status of and remotely control fee embedded devices 1804a and 1804b. In one embodiment, client 1806 
must present fee correct aufeorization credentials to control system 1800 to enable fee cUent 1806 to access 
embedded devices 1 804a and 1 804b. In one embodiment, client 1 806 may be granted access at different levels. For 
20 example, client 1806 may only be able to view fee status of embedded devices 1804a and 1804b but not be allowed 
to remotely control fee devices. In one embodiment, control system 1800 may be a service, m^ have a service 
advertisement published in fee distributed computing environment, and feus may be accessed by cUent 1806 using 
fee client-service mefeod as described previously in this document In one embodiment, client 1806 may be able to 
view fee status of, and to remotely control, control system 1800. 
25 Figure 40b iUustrates cUent control system 1808 connected via fee Internet 1802 to embedded devices 

1804c and 1804d, according to one embodiment In one embodiment, embedded devices 1804c and 1804d may 
include a thin implementation of fee XML messagmg system for communicating wife client control system 1808 
over fee Latemet 1 802. CUent control system 1 808 may have an unplementation of fee XML messaging system for 
sending requests to and receiving responses from embedded devices 1804c and 1804d. In one embodiment, client 
30 control system 1808 may include software and hardware configured to present an interface to allow a user to display 
fee status of and remotely control fee embedded devices 1804c and 1804d. In one embodiment, cUent control 
system 1800 may include software and/or hardware for automatic control of embedded devices 1804c 

A difference between Figure 40a and Figure 40b is that, in fee embodiment illustrated in Figure 40b, fee 
embedded devices 1804c and 1804d may be accessed by one or more clients in fee distributed computing 
35 envuonmentwifeout reqmringaproxy (e.g. control system). Embedded devices 1804c and 18044 may include 
services for accessing fee functionality of fee devices, may have published service advertisements in fee distributed 
computing environment, and feus may be accessed via fee cHent-service mefeod as described previously in this 
document 

The distributed con^utmg environment may include a mechanism for a resource-limited cHent to retrieve 
40 Universal Resource Identifier (URI) addressed resources. For example, a cUent feat is only capable of sending and 
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receiving messages via an IrDA connection may not be able to establish a URI comiection to retrieve results from a 
results space. In one embodiment, a service may be provided as a bridge between the client and the URI resource. 
The bridge service may interact with the client via XML messages to gather input parameters. The following is 
mcluded as an example of XML input message syntax and is not intended to be limiting in any way: ; 
5 <typename=*'HttpGef'> 

<element name="ur}string" type="string"/> 

<ytype> 

Then, outside the distributed computing envkonment, the bridge service may establish a URI connection 
10 and retrieve the resource. The resource m^ then be encapsulated as a payload in one or more XML messages and 
sent to the Ghent by the bridge service. - 

The following illustration of one possn>le use of embedded devices with thin hnplementations of die XML 
messaging system is mcluded for exemplary purposes and is not intended to be hmiting, A building may include a 
plurality of electronic devices that consume energy (e.g. Hghts, air conditioners, office equipment), and thus may 
15 require a system for mamtammg an optimum energy consumption level Hie plurality of devices may each mclude 
an embedded device for controlUng the electronic devices. The embedded devices m^ include the diin 
implementation of the XML messaging system. One or more control systems may be coupled to tiie devices in a 
network, for example, a building LAN or even the Internet A control system may store and execute a building 
management software package and an implementation of the XML messagmg system configured to be nsed by the 
20 software package for monitoring and controlling the devices. The control system may accept mput from users, and 
may display and otherwise output status mfonnation for the building energy consumption system, includmg status 
mforaiation for each of the plurality of devices. Energy consumption mjry be monitored by receivmg XML status 
messages from each of the plurality of devices. When energy consumption levels need to be adjusted, XML control 
messages may be sent to one or more of the devices to cause the energy consumption to change. 

25 

Implementing Services. 

In one embodhnent, the distributed computing environment may provide a mechanism for implementing 
services as servlets. The mechanism may provide fimctionaKty for developing services for the distributed 
computing environment 

30 In one embodiment, an Application Programming Mterfece (API) may be provided that provides the 

fimctionaHty to allow the service to be mitialized and registered m a space. In one embodiment, the API may 
be used to invoke the mitialization of the service and to generate an mitialization status page, for example, an 
HTML page, that may define the status of the service. A user may access the status of the service by accessing the 
status page from a browser, hi one embodhnent, the API may be used to process incoming messages and to 

35 generate documents in response to the messages. 

An embodhnent of the servlet mechanism may provide several fimctions includmg, but not Imiited to: 

• Management ofthe client connection to the service (unique session ID) 

• Management of an activation space that may be used to store results advertisements 

• Management of leases on connections sessions and results m activation spaces 
40 • Garbage collection of sessions and results 
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♦ Authentication of clients 

• Generation of client capabilities on a per session basis 

In one embodiment, the distributed computing environment may provide a service cascading mechanism by which 
new, complex services may be constructed jfrom other existmg services. For example, from a JPEG-to-PostScript 
transformation service and a print service, combining the transformation and print service may create a third 
cascaded service. In one embodiment, two or more services may be combined into a complex service by defining 
access methods of the two or more services as the access methods of the cascaded service. The following service 
advertisement for a cascaded service is included for exemplary purposes 
and is not mtended to be limiting in any way: 

<Service> 
<name>Complex Servicedname> 
<JD>,.,</ID> 

<descriptioi£> .... </description> 

<AccessMethod> 

<AccessMethod> 

<name>com-transcode- jpg2psdname> 

<implementation>httpy/www.transcode.com/software/jpg2ps.jardimplementatio 

</AccessMethod> 
<AccessMethod> 

<name>com.printeritpPrint</name> 

<impIementation>ht^://vmw.printerxom/software/ftpprmtjar<Vi^^ 
<yAccessMethod> 
</AccessMethod> 

<yService> 
Conclusion 

Various embodhnents may further include receiving, sending or storing instructions and/or data 
implemented in accordance with the foregoing description upon a carrier medium. Generany speaking, a carrier 
medium may mclude storage media or memory media such as magnetic or optical media, e.g., disk or CD-ROM, 
volatile or non-volatile media such as RAM (e.g. SDRAM, RDRAM, SRAM, etc.), ROM, etc. as well as 
transmission media or signals such as electrical, electromagnetic, or digital signals, conveyed via a communication 
medium such as network and/or a wireless link. 

Various modifications and changes may be made as would be obvious to a person skilled in the art having 
the benefit of this disclosure, it is intended that the invention embraces all such modifications and changes and, 
accordingly, the specifications, appendices and dmwmgs are to be regarded in an illustrative rather than a restrictive 
sense. 
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WHAT IS CLAIMED IS: 

I . A method for accessing a service in a distributed computing environment, comprising: 
a client locating a first service^itiiin the distributed con^>uting environment; 

the cHent requesting a capability credential to aUow the cUent access to a portion of the first service's 
capabilities, wherein said requesting a capability cmiential comprises the client indicating a set of 

desired capabilities; 
Ihe client receiving said capabiUty credential, whereta said capability cr^^^^ 

the right to use said portion of the first service's capabilities; and 
the cUent using said capabiBty credential to access one or more of said portion of the finrt scm 

capabilities. 

2 Hie method as recited in claim 1. wherein said requesting a capability credential comprises the client 
sending a capability credential request menage, therein said capability credential request message comprises an 
15 identification ofsaid first service and an indication ofthe set of desired capabiUties. 

3. The method as recited in claim 2. 'wherein said identification of said first service comprises a Universal 
Unique Identifier (UUID). 

4. Tbe method as recited in claim 2. wherein said capability credential request message if formatted m 
extensible Markup Lai^age (XML). 



20 



5 The method as recited in claim 2, finther comprising: 

the client receiving an advertisement for the first service, wherein said advertisement describes the portion 
25 of the first service's capabilities; and 

wherein said indication of the set of desired capabilities comprises an indication of said advertisement 



6. The 



method as recited in claim 5. wherein said indication of said advertisement is said advertisement itselt 
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7. Uemethodas«>citedinclaim5,wheremsaidindicationofsaidadvertisementisaUniformRe» 
Identifier (URI) to said advertisemeaiL 



8 ThemethodasrecitedmcIaim5,whereinsaidadvertisementdescnTK«aUofthefin=tsem^^ 
and wherein said indication of said advertisement m said capabQity credential r^^^^ 
35 advertisement edited to describe only said set of desired capabilities. 

9. m method as recited in claim 5. wherein said advertisement is a protected advetti^^^ 
the first service's capabilities but does not provide an interface to the first service^ 
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10. The method as recited in claim 1, further comprising: 

the client receiving a protected advertisement for the Jfirst service, wherein said protected advertisement . 

indicates an address for sending said capability credential request message to; and 
wherein said requesting a capability credential comprises die client sending a capability aedential request 

message to said address indicated in said protected advertisement 

11. The method as recited in claim 10, wherein said address mdicated in said protected advertisement is for an 
authentication service, wherein said sending a capability credential request message comprises sending said 
capabiUty credential request message to said authentication service, the method further comprising the 
authentication service sending a credential request response message to the client in response to said capabili^ 
credential request message. 

12. The method as recited in claim U, wherein said credential request response message includes said 
capability credential, wherein said receiving said capabihty credential comprises receivmg said capabihty credential 
from said authentication service in said credential request response message. 

13. The method as recited in claim l,fiutiier comprising: 

the client receiving a protected advertisement for tiie first service, wherein said protected advertisement 

indicates an authentication service; and 
wherein said requesting a capabihty credential comprises the cUent requesting a capabUity credential from 

said authentication service. 

14. The method as recited in claim 13, the method further conaprising: 

said authentication service detemiimng a level of the first service's capabilities tiiat the cUent is authorized 
to use; 

said authentication service generating said capability credential accordmg to said level and said set of 
desired c^abilities; and 

said authentication service sending said capabihty credential to tiie client, wherein said portion of the first 
service's capabilities that said capability credential indicates that flie client has a right to use is no 
more than said set of desired capabilities. 

15 The method as recited in claim 14, wherem said portion of the first service's capabiHties tiiat said 
^abiHty credential indicates that die cUent has a right to use is flie lesser of smd level of die first service's 
capabilities that the client is authorized to use and said set of desired capabiUties. 



Ci 



16. The method as recited in claim 1, wherein said usmg said capability credential to access one or more of 
said portion of the first services capabihties comprises tiie client sending a message to the first service to access a 
first capabihty, wherem tiie message mcludes said capabihty credential, the method finther comprismg tiie first 
service authenticating said capabihty credential received in the message to verify tiiat tiie client has tile right to use 
said first capability. 
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17. A client device, comprising: 

a connection to a distributed computing environment; 

an interface coupled to said connection and configured to locate a first service within the distributed 
computing environment; 

wherein the interface is further configured to request over the connection a capability credential for a set of 
desired capabilities to allow tiie client on the client device access to a portion of the first service's 
capabilities; 

wherein the interface is further configured to receive over the connection said capability credential, wherein 
said capabihty credential indicates that the client has the right to use said portion of the first 
service's capabilities; and 

wherein itxe mterface is further configured to use said capability credential to access one or more of said 
portion of the first servicers c^)abilities. 

18. The client device as recited m claim 17, wherein the interfece is configured to request a capability 
credential by sending a c^abiHty credential request message, v^dberein said capabihty credential request message 
comprises and identification of said first service and an indication of die set of desired capabifities. 

19. The client device as recited m claim 18, wherein said identification of said first service comprises a 
Universal Unique Identifier (UUID). 

20. The client device as recited in claim 18, wherein said capability credential request message if formatted in 
extensible Markup Language (XML). 

21. The cUent device as recited in claim 18, \^^erein the interface is fiirther configured to receive an 
advertisement for the first service, wherein said advertisement describes tiie portion of the first service's capabifities, 
and wherein said indication of the set of desired capabifities comprises an mdication of said advertisement 

22- The cUent device as recited m claim 21, wherein said indication of said advertisement is said advertisement 
itself. 

23. The client device as recited m claim 22, wherein smd mdication of said advertisement is a Uniform 
Resource Identifier (URI) to said advertisement 

24. The client device as recited in claim 21, wherein said advertisement describes aU of the first servicers 
capabifities, and wherein said indication of said advertisement in said cq)abifity credential request message m a 
version of said advertisement edited to describe onty said set of desired capabifities. 

25. The cUent device as recited in claim 21, wherein said advertisement is a protected advertisement tiiat 
describes the first service's capabilities but does not provide an interface to tiie first service's capabifities. 
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26. TTie cUent device as recited in claim 17, wherein tiie interfece is further configured to receive a protected 
advertisement for the first service, wherein said protected advertisement indicates an address for sending said 
capabUity credential request message to, and wherein the interfece is configured to request a capability clcdential by 
sending a capability credential request message to said address indicated in said protected advertisement 

5 

27. The client device as recited in claim 26, wherein said address indicated in said protected adver^^^ 
for an authentication serace. wherein said sending a capability credential request mess^^ 

capability credential request message to said authentication service. 

10 28: The client device as recited in claim 27. wherein &e interfece is configured to receive said c^bffity 
credential from said authentication service m a credential request response message. 

29. The client device as recited in claim 17, wherein the interfece is finlher configure to: 

receive a protected advertisement for tiie first service, wheiem said protected advertisement indicates an 

15 authentication service; and 

request a capabihty credential by requesting a capabiUty credential fiiom said authentication service. 

30. The client device as recited in claim 29, wherein said portion of tiie first service's capabilities that said 
capability credential mdicates that the client has a right to use is the lesser of said level of the first service's 

20 capabiUties that the client is authorized to use and said set of desired capabilities. 

31. The client device as recited in claim 17. wherein Ac interface is configured to use said capabiHty credential 
to access one or more of said portion of the first services capabiUties for said client by sending a message to the first 
service to access a first capability, wherein the message includes said capability credential so that the fin* service 

25 may authenticate said capability credential received m the message to verify that the cUent has tiie right to use said 

first capability. 

32. The cUent device as recited in claim 17, wherem said interfece coinprises one or more processes execute^^^ 
on a processor within tiie client device. 
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33. A carrier medium comprising program instructions, wherein &e program mstructions are computer- 
executable on a client device to implement: 

locating a first service within the distributed computing environment 

requesting a capability credential to allow a client on the cUent device access to a portion of the first 
service's capabilities, wherem said requesting a capabiUty credential comprises tiie client 
indicating a set of desired c^abilities; 
receivmg said capability credential, wherein said capability credential indicates that the client has the right 
to use said portion of the first service's capabilities^ and 
V usingsaidcapabiUtycredentialtoaccessoneormoreofsaidportionofthefi^ 
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34. n,e carrier medium as recited in claim 33, ^vherein said requesting a capabiUty credential comprises the 
client sending a capability credential request message, wherein said capability aedential request mess 

an identification of said first service and an indication of theset of desired capabilities. 

5 35. The earner medium as recited in claim 34. wherein said identification of said first service comprises a 
Uniwarsal Unique Identifier (UUID). 

36. TTiecamermediumasredtedindaim34,wherejnsmdcapabilitycredentidreqneStmessageifform^ 
in extensible Markup Language (XML). • i 

10 

37. Hie carrier medium as recited in claim 34. wherein the program instructions are computer-executable on 

the client device to fiirther implement 

receiving an advertisement for the first service, wherein said advertisement describes the portion of the first 

service's capabilities; and 

15 wherein said indication ofthe set ofdesiredcapabiUties comprises an indication of said advertise^^^ 

38. The carrier mediimi as recited in claim 37. wherein said indication of said advertisement is said 

advertisement itself 

20 39. Tho carrier medium as recited in claim 37, wherein said indication of said advertisement is a Uniform 
Resource Identifier (URI) to said advertisement 

40. The carrier medium as recited in claim 37, wherein said advertisement describes all of the &st service's 
capabilities, and wherein said indication of said advertisement in said capability credential request message in a 

25 version ofsaid advertisement edited to describe only said set of desired capabilities. 

41. The carrier medium as recited m claim 37. wherein said advertisement is a protected advertisement fliat 
describes the first service's capabilities but does not provide an interface to tiie first service's capabiUties. 

30 42. Tlie carrier medium as recited in claim 33. wherein the program instructions are computer-execute^^^ 

die client device to fiffther implement 

receiving a protected advertisement for the fct service, wherein said protected advertisement indicates an 

address for sending said capability credential request message to; and 
wherein said requesting a capability credential comprises flie client sending a capabiUty credential 
35 message to said address indicated in said protected advertisement 

43. The carrier medium as recited in claim 42, wherein said address mdicated in said protected advertisement 

isforanaufl.enticationservice.whereinsaidsendingacapabiUtycredentialrequ^ 

capabiKty credential request message to said aiiflientication service. . 

40 
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44. He cairier medium as recited in claim 43. wherein said receiving said capability credential comprises 
receiving said capability credential from said authentication service m a credential request response message. 

45. The carrier medium as recited m claim 33, wherein the program instructions are computer-executable on 
the client device to further unplement 

receiving a protected advertisement for the first service, wherein said protected advertisement indicates an 
authentication service; and 

wherein said requesting a capabiUly credential comprises the cUent requesting a capability credential from 
said authentication service. 

46. The carrier medium as recited in claim 45, wherein said portion of the first service's capabilities tot said 
capability credential indicates that «»e client has a right to use is fte lesser of said level of the first service's 
capabilities that the cUent is aufliorized to use and said set of desired capabilities. 

47. The carrier medium as recited in claim 33. wherein said using said capability credential to access one or 
more of said portion of the first services capabilities con^rises the cUent sending a message to the first service to 
access a &st capability, wherein the message includes said capability credential so that the first service may 
authenticate said capability credential received m the message to verify that the cUent has the light to use said first 

capability. 
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